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ABSTRACT 


The necessity for well-defined, integrated information systems (IS), .driven 
by today’s dwindling human, financial, and management resources, makes it 
essential to plan effectively. This can only be achieved by linking IS planning to 
the overall strategic plan of the organization. Department of the Navy (DON) 
IS planning has historically missed the mark in this respect. Information 
Engineering (IE), automated through Computer Aided Software Engineering 
(CASE) technology, offers significant benefits for improving DON IS planning. 
Two CASE workbenches. Information Engineering Systems Corporation’s USER: 
Expert Systems and Texas Instruments’ Information Engineering Facility, have 
proven highly effective in automating IE in DON applications. 
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1. INTRODUCTION 


The management of information systems (IS) development in the 
Department of the Navy (DON) has historically suffered from the lack of a solid 
planning foundation, as evidenced by the proliferation of non-integrated, 
redundant, application-driven systems that exist throughout the service. This is 
due to a variety of reasons. First, planners suffer from the fact that they deal 
with an uncertain and distant future, • ;ith the possibility of achieving no tangible 
benefits until long after the incumbent planner has departed. As such, planning 
is perceived by many as a significant and unnecessary resource drain. In addition, 
forecasting inaccuracies due to inadequate knowledge of the social, political, 
cultural, and economic forces at work in the environment add elements of risk 
and uncertainty that further complicate the planning effon. Differences in 
perceptions regarding organizational priorities and industry trends between top 
management and IS personnel also adversely affect planning. Finally, planning 
has often been carried out as a meaningless, mandated, ritual rather than as a 
highly utilized operational tool. All these factors lead to a lack of commitment 
from top management down, thereby undermining the overall IS planning effort 
of the organization. 
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A heavy price may be paid as a result of inadequate IS planning. Without 
the benefit of a solid planning foundation, information and integration 
requirements are often short-sighted and incomplete, and as such, represent the 
basis for systems that will not meet the overall information needs and mission of 
the organization. The result; huge software maintenance costs comprising up to 
eighty percent of total lifecycle costs. On the other hand, an effective planning 
effort will serve as a basis for systems that promote corporate strategy, improve 
overall performance, and facilitate communications between management and 
systems personnel. 

Despite the unfavorable perceptions that exist regarding planning, there are 
considerable pressures to plan effectively. First, in today’s budget climate, 
effective planning is vital to ensure continued fimding for systems throughout their 
lifecycle. For FY 1990, the House of Representatives Committee on 
Appropriations mandated cuts of $300.75 million in the Department of the Navy 
ADP budget, including a $70 million cut directly attributable to Navy 
mismanagement of ADP programs. [Ref. 1 :p. 39] As a result, there will be 
increased emphasis on strategic and IS planning in the future to prevent huge cost 
growths, redundant systems, and development of systems that do not meet 
strategic information needs of the organization. Secondly, rapid changes in 
technology emphasize the importance of planning at all levels in order to avoid 
the proliferation of incompatible, incomplete information systems. Finally, the 
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necessity for efficiency, driven by dwindling human, financial, and management 
resources available to organizations, make it essential to plan effectively. As the 
vision of information as a corporate resource continues to evolve, there will be 
increasing motivation to develop integrated, organization-wide information systems. 
These systems can be successful only if the development process is based on a 
solid foundation of strategic information systems planning. 

As the significance of information systems to fulfilling the corporate mission 

increases, so does the necessity to link systems planning with the strategic 

objectives of the organization. Aligning the strategic information systems plan to 

the corporate strategic plan will ensure that the organization will be in a position 

to exploit emerging technologies and industry trends, while continuing to develop 

systems that fully support its information requirements. Establishing the linkage 

between strategic and IS planning is essential for an organization in many ways: 

First, it is important to know how a change in the strategic planning of an 
organization would affect the planning of information technology because 
changes in the infrastructure of an organization take years to evolve. It is 
important to analyze these changes early and identify the cultural issues that 
are unique to each organization because a significant level of planning and 
resources is needed for cultural change to happen. Second, senior executives 
strongly desire to regain effective control in the aftermath of the information 
technology explosion. This control can be achieved through strategic 
planning at both organizational and technological levels in order to align 
development efforts with strategic business objectives, j.lans, and priorities. 
This desire is due largely to senior executives’ recognition that information 
systems are becoming the critical path in effeaing critical changes in an 
organization. [Ref. 2:p. 218] 
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Many methodologies and tools have been introduced throughout the years 
designed to improve the process of developing computer-based information 
systems. The vast majority of these methods have fallen woefully short in support 
of strategic systems planning. However, two methodologies have proven effective 
for aligning strategic and information systems planning. [Ref. 3:p. 448] The first. 
Business Systems Planning (BSP) was developed in the late 1960’s by IBM, and 
was the first systems development methodology to recognize the need to link IS 
planning to strategic plarming, and to emphasize data as a corporate resource. 
[Ref. 4:p. 103] The second, Information Engineering, was developed in the 1970’s 
by James Martin and Clive Finkelstein as a strategic information systems 
development methodology supporting the entire lifecycle. [Ref. 3:p. 449] This 
thesis will examine and compare them, and discuss the suitability of using each 
in the context of Department of the Navy (DON) applications. 

The thesis examines the efforts of the Department of the Navy in aligning 
strategic and information systems planning, and will present recommendations for 
facilitating this process. SECNAV Instruction 5230.9A, the Information Resource 
(TR) Program Planning guide, and SECNAV Instruction 5230.10, the Department 
of the Navy Strategic Plan for Managing Information and Related Resources 
(IRSTRATPLAN), document the Navy’s commitment to a top-down approach to 
strategic IS planning. However, in practice, its efforts have not been particularly 
successful. Huge cost overruns, unnecessary duplication, the inability to integrate 
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existing systems, and overall program mismanagement have resulted in a loss of 
credibility and confidence for the DON in Congress. There are several reasons 
for these difficulties. One of the primary reasons is the lack of understanding by 
top DON management of Information Resource Management (IRM) issues, and 
in particular, the methodologies and tools available for aligning its overall 
strategic planning and IS planning. Uneasiness regarding the need for IRM and 
IR planning, the organizational structure required to support IRM, and the 
relative strengths and weaknesses of the various IS planning tools and 
methodologies, all add to the reluctance of top management to embrace these 
issues. Second, the reluctance of top management to commit considerable 
resources to what is perceived to be an uncertain process, further complicate the 
IRM and IR planning process. It is important for DON management to 
understand that IS planning methodologies are not a panacea and do not provide 
an overnight payback. The large up front investment in time and capital required 
will yield benefits downstream, and over the long nm, not overnight. A 
commitment to education at all levels of both the IS and line communities is 
required to improve the overall performance of DON system development and 
program management. In addition, environmental factors such as political issues, 
budgetary constraints, and the inefficiencies of the Life Cycle Management (LCM) 
process when applied to IS development and acquisition, further hinder IRM and 
IR planning efforts in the DON. 
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The thesis will address the following questions: 


1. Which CASE tools are the most suitable for aligning strategic and IS 
planning in the Department of the Navy (IX)N)? 

2. Why have IS planning methodologies been under-utilized in the DON? 

3. Are DON organizations the size of Type Commanders (TYCOMS), such 
as CINCLANT, or Systems Commands (SYSCOMS), such as NAVSEA or 
NAVSUP, too large and complex to effectively utilize these methodologies 
in support of IS planning efforts? 

4. Are DON activities effectively aligning their IS plans to the overall 
strategic objectives of their organization and the DON as a whole? 

5. What are the benefits to the organization of applying IS planning 
methodologies to systems development projects? 

6. Is Information Engineering suitable for use as a strategic planning tool 
outside the realm of ADP? 


Chapter II will provide background information on the interrelationship and 
importance of strategic planning and information systems planning. In addition, 
it will examine the strengths and weaknesses of Information Engineering and 
Business Systems Planning as IS planning methodologies. 

Chapter III will evaluate IR planning in the Department of the Navy, by 
examining the plaiming process, and the difficulties currently hindering the 
process. In addition, it will examine the potential implications of the DoD- 
directed Corporate Information Management (CIM) initiative. 

Chapter IV will discuss the benefits of applying Information Engineering and 
Computer Aided Software Engineering (CASE) technology to the DON IR 
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planning process, and will present recommendations to facilitate its use. It will 
then examine and compare three commonly used CASE workbenches that 
automate some or all of the Information Engineering process. In addition, the 
lifecycle coverage of these toolsets will be compared in the context of an 
analytical framework for comparing information engineering methodologies, 
developed by Hackathom and Karimi. [Ref. 2:p. 204] The following CASE 
workbenches will be examined; 

1. Information Engineering Systems Corporation’s "User: Expert Systems", 

2. Texas Instrument’s "Information Engineering Facility", 

3. KnowledgeWare’s "Information Engineering Workbench" 

Finally, Chapter V will present conclusions and recommendations for 
improving the IR planning efforts of the Department of the Navy. 
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11. ALIGNING STRATEGIC AND INFORMATION SYSTEMS PLANNING 


A. STRATEGIC PLANNING 

Strategic planning is the process of deciding on objectives of the 
organization, on changes in these objectives, on the resources used to attain 
these objectives, and on the policies that are to govern the acquisition, use, 
and disposition of these resources. Strategic planning. . . is a process 
having to do with the formulation of long range, strategic plans and policies 
that determine or change the character or direction of the organization. 
Robert Anthony [Ref. 4:p. 8] 

From the definition, one can see that strategic planning is proactive in 
nature, and deals with issues, impacts, and potential strategies for accomplishing 
business objectives. It is a comprehensive, iterative, three-stage process for 
exercising favorable influence over future events. The process starts with strategic 
planning and continues through strategic implementation and strategic 
management. As a result of feedback during the implementation and 
management of the plan, it is continuously refined. (Figure 1) In the first stage, 
the organization is analyzed to determine where it stands, and where it must go. 
This analysis examines the organization as a dynamic and adaptable system that 
is affected by and interrelates with the following forces: external, social, cultural, 
political, economic, and competitive. [Ref. 6:p. 205] Understanding these forces, 
how they interrelate, and what threats and opportunities they create, is vital for 
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Figure 1. Strategic Planning Life Cycle [Ref. 5:p. 160] 
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effective strategic planning. In addition, the availability and development of 
corporate resources such as plant and equipment, personnel, capital, and data 
must be considered. From this organizational analysis, goals and objectives are 
set, and strategies for achieving these goals must be developed. For example, a 
typical strategy statement would be: "Effectively manage inventory". In stage two, 
these strategic directions are communicated to the organization via the setting of 
management objectives, and then implemented through supporting strategic, 
tactical, and operational plans and policies. At this point, the strategy statement 
has been refined and strengthened to include specific plans and policies for 
executing the strategy. Thus, the above strategic statement is supplemented with 
statements such as: "Adjust inventory levels according to demand or in accordance 
with policy", or "Prioritize inventory management by mission essentiality," Finally, 
in stage three, these plans and policies are executed and managed by the 
organization. During this stage, feedback and performance criteria must be 
monitored to ensure the success of the organization. Problems in the plan are 
identified, and refinements are instituted as necessary. 

B. STRATEGIC INFORMATION SYSTEMS PLANNING 

In organizations where information is a vital resource, such as the 
Department of the Navy, strategic planning and information systems planning must 
be closely tied. The IS planning process must be an integral part of the overall 
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business plan of the organization in order to achieve the optimal fit between 
organizational requirements and IS functions. [Ref. 7:p. 4] An effective 
information systems plan that has been closely aligned to strategic business 
objectives holds significant advantages for the organization. First, it promotes 
commitment from top level management, as they will be more willing to provide 
adequate resources for systems that are strategically important, and from 
information systems personnel by making them stakeholders in the success of the 
organization. Second, it enhances both lateral and vertical communications within 
the organization since all components are supporting mutually agreed upon 
objectives. Third, an effective strategic IS plan provides focus and constraints on 
resource allocation by narrowing the scope of organizational objectives. Similarly, 
the project selection process is streamlined by the assurance that only those 
projects which directly support the business and IS plans will be developed. The 
requirement to develop systems that "put out fires" will be reduced. Finally, the 
strategic IS plan provides a vehicle for managing changes in technological, 
environmental, and organizational climate. By anticipating and planning for future 
requirements, the strategic IS plan facilitates the timely and orderly introduction 
of systems designed to ensure continued organizational success. 

In general, development of an effective IS strategic plan supplements the 
formulation of the strategic business plan. It involves a three step process starting 
with strategic IS planning, then moving to tactical IS planning, and finally, to 
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operational IS planning. Strategic IS planning links organizational needs and 
information resources and entails evaluating environmental and organizational 
factors, deciding on objectives, and formulating policies. 

Strategic IS planning begins with a determination by management of where 
the organization stands in the evolution of its data processing function. Two IS 
planning models are highly effective at determining the current state of 
employment of information technology and information systems within an 
organization; McFarlan and McKenney’s Strategic Grid, and Nolan’s Stages of 
Growth model, 

1. The Strategic Grid 

For some organizations, IS activities play a vital and strategic role, not 
only in their daily operations, but also in the development of their future 
applications portfolio, as a way of achieving competitive success. On the other 
hand, IS activities may play only a minor, supporting role in the organization. 
Further the role of IS in the organization may be either increasing or decreasing 
at any given point in time. Whatever the case, it is vitally important for 
management, both IS and senior -level, to examine the role that IS plays in their 
organization. The Strategic Grid approach, developed by McFarlan and 
McKenney of Harvard Business School, maps the role and strategic impact of 
IS to the organization in un extremely simple, yet highly useful manner. 
[Ref. 8:p. 152] The four quadrant grid graphs the strategic impact of existing 
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information systems, on the vertical axis, against the strategic impact of the 
organization’s planned application development portfolio., on the horizontal axis. 
(Figure 2) Based on its placement on each of the two axes, an organization is 
mapped into one of the four quadrants: Strategic, Turnaround, Factory, and 
Support. 

Organizations that fall into the Strategic quadrant are critically 
dependent on the efficient daily fimctioning of their existing IS activity, and have 
applications under development that are essential to their continued competitive 
success. Banking firms and airlines are excellent examples of firms that reside 
in the Strategic quadrant. These organizations must place a high degree of 
emphasis on IS planning in order to maintain a proactive stance. To do this, 
there should be little organizational distance between top management and IS 
management. In addition, clear and formal lines of communication should be 
established and maintained to ensure close cooperation between the two. 

There are many organizations that are highly dependent on their current 
IS activities, but are not dependent on their future applications portfolio for 
continued strategic success. These organizations fall into the Factory quadrant of 
the Strategic Grid. Large manufacturing and distribution firms may fall into this 
category. Much of the day-to-day operations of these organizations is dependent 
on the smooth and efficient operation of their IS activity. The applications 
portfolio of these firms contains maintenance work and "back-room" applications 
that, although important, will not significantly affect the ability of the organization 
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to compete. As a result, IS planning has a short term, operational management 
perspective, with an emphasis on cost savings and efficiency. 

Other organizations depend neither on their current IS activities nor 
their future applications development portfolio, for their continued strategic 
success. These organizations fall into the Support quadrant. Large manufacturing 
firms may also fall into this quadrant. In these organizations, IS management is 
at a much lower organizational level, and the priority placed on IS planning is 
equally low. 

Many firms, on the other band, may have a future applications 
development portfolio that is vital to their continued ability to compete, even 
though the strategic impact of existing IS activities is low. Rapidly growing 
organizations are often in the Turnaround position. These firms are in a 
transitionary period in their IS development. They have yet to develop a high 
dependency on IS support, yet they realize the strategic importance and futme 
competitive benefits of information systems. As a result, the organizational 
position of IS management is rising to reflect its new strategic significance. 
Further, top management is increasing its commitment to IS planning through 
"a revised reporting structure, increased top-level participation in IS steering 
committees, and more intense user involvement in establishing priorities." 
[Ref. 9;p. 152] An organization must move through the Turnaround quadrant in 
order to move from Support to Strategic. This is implicitly obvious as a firm in 
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the Support stage must make a commitment to increasing the strategic significance 
of its applications portfolio in order to move on to the Strategic quadrant. 

The Strategic Grid is useful not only for characterizing the organization 
as a whole, but also for examining the role of IS in individual business units. 
This is important as individual business units in the same organization may have 
radically different positions on the grid. The placement of an organization or a 
business unit on the grid has several important implications. First, it provides 
management with an effective diagnostic tool for determining where they stand 
in terms of their IS activity, and therefore gives them an indication as to where 
and how best to conduct their IS planning efforts. It also provides a 
comprehensive picture of the degree to which IS planning efforts must be 
integrated into overall organizational planning. The actual position of the 
organization on the grid, and its position on the grid as perceived by senior line 
and IS management are vital inputs to the IS planning process. So to, is the 
desired position on the grid that the organization wishes to attain. Second, it 
establishes the strategic role of the IS function- its operations, the role of its 
management, and its future role in the organization. As such, it provides 
management with a toe’ determining the organizational placement of IS, and 
suggests the required level of involvement of general management and the role 
of the executive steering committee. Similarly, it suggests an appropriate type of 
management control system for the organization and its individual business units. 
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It also suggests the need for a flexible, dynamic planning and control approach 
when the role of IS is changing over time. Finally, it serves to determine the 
degree of importance of the information resource to the organization, and the 
nature of effort that must be undertaken to develop it. As such, it is an effective 
starting point for any strategic IS planning effort. The main disadvantage of 
the approach is that it doesn’t provide any tools or clear criteria for determin¬ 
ing where an organization or business unit should be located on the grid. 
[Ref. 7:p. 12] This is left up to the subjective evaluation of management. 
Determining the location of the DON on the grid is a significant task because of 
its complexity, and the varying degrees of importance that information technology 
plays in its organizations. 

2. Nolan’s Stages Of Growth 

Nolan’s Stages of Growth is a six-stage model that examines the growth 
of an organization’s DP function, from its inception the mature management of 
data resources. The model was originally conceived as a four stage model, but 
was modified to six stages as a result of the continued increase in complexity of 
the DP environment. During the first three stages, DP management is concerned 
with management of the computer. At approximately the middle of stage three, 
there is a transition to management of the data resource. (Figure 3) The model 
is a useful strategic IS planning tool in that it provides management with a 
diagnostic tool for identifying the current state of the organization’s IS function, 
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STAGE 1 STAGE 2 STAGE 3 STAGE 4 STAGE 5 STAGE 6 

Slow DP Growth Attempts to Application Some slowing DP growth 

growth speeds up introduce development of growth tracks the 

as controls and fagtgr due due to sales growth 

application retrofit Class III further of the 

development applications bases attempts to organization 

spreads slows DP integrate 

growth 

INITIATION CONTAGION CONTROL INTEGRATION DATA ADMIN. MATURITY 


Figure 3, Nolan’s Stages of Growth [Ref. 9:p. 81] 
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and what must be accomplished to evolve to the next stages. According to the 
model, an organization starts at the first stage, Initiation, and must evolve through 
every subsequent stage before reaching maturity in its DP function. The six 
stages are described below: [Ref. 9:p. 


1. Stage 1: Initiation: Initial development of an organization’s first 
applications- generally "back-room", administrative and accounting 
applications. No overall DP control. 

2. Stage 2; Contagion: Enthusiasm. Growing demand for, and proliferation 
of, applications. Applications developed in isolation causing incompatible 
and redundant data. Lack of planning and control mechanisms. 

3. Stage 3: Control; Management attempting to gain control of DP function 
due to user frustration, high maintenance costs, and a long applications 
backlog. Management upgrades documentation, restructures existing 
applications, introduces data base management, and formalizes planning and 
control mechanisms. Slow application development as a result of DP 
rebuilding and restructuring. Perceived need for Data Administration, 
although little action taken. 

4. Stage 4; Integration: Existing applications retrofitted to data base 
technology. Successful Class III data bases lead to fundamental changes 
in applications development process. Increase in demand for DP. 
Increased DP growth and expenditure. Redundancies of data and lack of 
enterprise-wide information analysis hinder attempts to develop planning 
and control applications. 

5. Stage 5: Data Administration: Information Resource Management. 
Enterprise-based strategic planning of the data resource. Stable data 
models and end-user computing. Class I data bases provide flexible and 
valuable IS and decision support systems. 

6. Stage 6: Maturity: Organization-wide information analysis and data 
modeling has been implemented. Applications mirror the enterprise. DP 
growth tracks the sales growth of the organization. 
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The transition point in between stages 3 and 4 represents the point at 
which applications development should become data base-driven rather than 
application-driven. Further, systems analysis and design moves from a procedure 
orientation to a data orientation. 

Nolan’s Stage model can be employed to analyze both the organization 
as a whole and its individual business units. An organization may have separate 
divisions that simultaneously reside in all six stages. Determining which stage the 
organization or business unit resides in can be a difficult process. Figure 4 gives 
a graphical representation of the benchmarks required to determine the placement 
of the organization. Taking a single benchmark by itself may be misleading, 
therefore management should examine all six benchmarks before determining their 
organization’s stage of DP growth. 

Managing the organization’s evolution through each stage of growth is 
a key challenge for IS and senior line management. Nolan has developed five 
guidelines for effectively managing and taking advantage of this growth. 
[Ref. 10:p. 122] First, he states that management must recognize the transition 
of the organization from computer management to information resource 
management. Managers must first recognize the change and then develop data- 
oriented applications and planning and control systems to facilitate the transition. 
Second, management must recognize the importance of new technologies that 
enable the smooth transition to data administration. Third, management must 
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identify the stage of DP evolution for each business unit in order to keep DP 
activities on track. By knowing where each unit stands in the evolution of its DP 
function, management can effectively plan for the future. Fourth, management 
should develop a multilevel IS strategy and plan. Nolan’s Stage model provides 
the first input to the strategic planning process by providing management with a 
way of determining their current state. Once management knows where the 
organization and each business unit stands, they can utilize the model to develop 
an IS strategy and growth plan that is aligned with the firm’s overall business 
strategy. Finally, top management must make the executive steering committee 
work. In order to effectively plan for IS, senior management must formulate a 
strategy, set priorities, and establish a favorable environment for IS growth. 

Nolan’s Stages of Growth model enables management to determine the 
most appropriate IS strategy for the organization, based on its current stage. It 
is also useful for diagnosing and understanding changes that must be made to 
facilitate the transition between stages. As such, it represents an easy -to - 
understand and powerful tool for beginning a strategic IS planning process. The 
major drawback to the model is that it gives a "snapshot" picture of the 
organization or business unit at a given time, and does not adequately show the 
direction of changes. Similarly, despite the benchmarks provided for determining 
the stage of growth, it can be extremely difficult to accurately map complex 
organizations such as the DON into a specific stage. 
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3. IS Strategy Development and Analysis 


Once the current stage of IS activity is known, an analysis of the 

strengths and weaknesses that bear on its IS strategies must be conducted. 

Internal factors, such as budgetary and human constraints, and external factors, 

such as competition, legislation, and the prevailing technological climate, must be 

considered. It is important to understand that: 

... the extent and complexity of corporate activity make it impossible for 
data processing to be ’all things to all people’. Consequently, decisions will 
have to be made on what data processing be -its priorities and purposes; 
when, where, and whom it will serve; and so on. If the DP management 
makes these decisions without the benefit of an agreed-upon strategy and 
plan, the decisions are apt to be wrong, if they are right, the rationale for 
them will not be adequately understood by users (and management). If 
users do not understand the strategic direction of data processing, they are 
unlikely to provide support. [Ref. 10:p. 126] 

Next, management must develop an IS strategic plan that fulfills the 
information requirements of the organization, and formulate policies with which 
to implement this strategy. As stated earlier, this IS strategy must be an integral 
part of the overall business plan to achieve the optimum match between the 
organization’s information requirements and the functioning of its IS component. 

The tactical planning phase is concerned with long and medium range 
(2-10 years) conceptual planning, and the development and formulation of the IS 
Master Plan. The IS Master Plan starts with needs, objectives, and constraints set 
forth in the strategic plan, and entails the following: 
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1. Requirements analysis; 

2. Assembly of an applications portfolio; 

3. Establishment of a priority scheme for the applications portfolio; 

4. Development of applicable information systems architectures. [Ref. 7:p. 4] 

In addition, it documents plans and policies for non-ADP support activities such 
as procurement or logistics. The IS architectures developed are graphical 
statements of flows, interfaces, and information, technical, and support 
requirements that illustrate how individual systems and components fit together 
to form an integrated comprehensive whole. Management must develop IS 
architectures that establish goals and strategies for each IS function in order to 
make them fully supportive of the overall business plan. The following 
architectures should be developed: data, information flow, technical, support 
systems, network, and any other applicable functions. Each architecture should 
illustrate: 

1. the current or baseline situation; 

2. the planned or interim situation when all currently programmed actions 
are implemented; 

3. the target situation. [Ref. ll:p. 2] 

Each architecture study will assist the planner in the refinement of the 
organization’s IS objectives. Without a solid grasp of how the goals of the 
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organization are translated into these architectures, application development efforts 
will have a short term perspective resulting in the development of isolated, 
fragmented systems that do not meet the overall needs of the organization. This 
problem is particularly evident in large, complex DON organizations, such as those 
at the SYSCOM and TYCOM level. (Figure 5) IS architectures serve "as a 
blueprint on which systems development activities can be: a) prioritized by 
deciding the sequencing for building the architecture; b) coordinated by relating 
to other systems in an efficient manner; and c) optimized by building each system 
with the corporate information requirements in mind." [Ref. 2:p. 204] 

There is significant volatility in the IS environment due to technological 
innovation, competition, changes in corporate strategies, and many other factors. 
This volatility places a premium on the successful development of flexible Master 
plan and architectures that will permit orderly and consistent change to match 
evolving organizational requirements. 

The operational IS planning phase involves the development of a 
detailed annual IS plan. This plan should include performance targets, resource 
allocation and budgetary decisions, specific tasks and schedules, and other 
activities required for achieving short range objectives. [Ref. 7:p. 5] The annual 
plan should be based on the broader objectives set forth in the Master Plan, in 
order to maintain a linkage between the day-to-day operation of the IS activity, 
and the strategic and tactical objectives of the organization. 
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C. METHODOLOGIES FOR LINKING STRATEGIC AND IS 

PLANNING 

1. Maintenance Hassles Drive the Need For a New Approach 

The maintenance of systems developed using traditional manual 
approaches such as Structured Analysis and Design is extremely high. The cost 
of this maintenance may add up to as much as four times the development cost 
over the life of the project. In addition, it may absorb some 60-80 percent of 
analyst and programmer resources, leaving only the remainder for the 
development of new systems. One of the primary reasons for these maintenance 
problems is the fact that these systems have traditionally been developed to meet 
narrow management needs, without regard for the strategic objectives of the 
organization. In addition, since the systems were developed using process-oriented 
techniques, they are highly susceptible to environmental pressures, and changes in 
management information requirements. 

IBM realized this problem, and developed Business Systems Planning 
(BSP) as a potential solution. [Ref. 13:p. 43] James Martin and Clive Finkelstein 
followed with the introduction of Information Engineering. [Ref. 9:p. 4] Both 
methodologies are data-oriented, and are based on a solid foundation of strategic 
planning. In addition, both accelerated systems development time, and had a 
significant positive impact on maintenance costs. 
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2. Infonnation Engineering 


a. Overview 

Information Engineering (IE) was introduced by James Martin and 
Clive Finkelstein in the 1970’s. [Ref. 9:p. 2] It represents the compilation of an 
interrelated set of disciplines required to build enterprise-based computerized 
information systems. In contrast to software engineering and structured analysis 
and design approaches, IE is specifically designed to draw on the strengths of the 
user, management, and DP personnel throughout the system development process. 
It is a data-oriented approach, and is based on the premise that data and 
information are two of the primary resources of an organization, and lie at the 
center of modem data processing. This data-oriented approach provides a solid 
foundation on which to build computer systems, because the structure of data 
does not change; the processes that use it do. IE provides the means to develop 
the "one and only one minimal nonredund£mt structure of the data," and this 
structure forms the foundation on which information systems can be built. 
[Ref. 9:p. 4] In addition, IE enables rapid response to the changing information 
needs of management, because procedures are able to be changed quickly because 
they are independent of the data. Procedure or process-oriented techniques, on 
the other hand, tend to produce systems that are difficult to implement in a 
timely manner, and which are unresponsive to changing requirements. Since they 
build systems based on the processes of an organization, they are subject to the 


28 







inherent instability and dynamic nature of those procedures. The goal of IE is 
to provide the means to fulfill management’s requirements for information rapidly 
and effectively, and to act as the primary implementation vehicle for achieving 
Information Resource Management (IRM). 

b. Methodology 

Information Engineering facilitates strategic systems development 
through the use of modeling. It models the organization in terms of its data 
resource, (data that is fundamental to the enterprise) and the policies, objectives, 
and strategies developed by management. The data model is based on the 
premise that the data used in an organization does not change significantly, while 
the p»‘ocedures that use it will. The banking industry is an excellent example of 
this premise. The procedures for personal banking have changed dramatically 
over the years, however the data behind them (deposit, withdrawal, and balance 
data) have remained essentially unchanged. Data changes only as the business 
itself changes. With an accurate data model, the organization can represent itself- 
its business, its products and services, and its markets - in terms of its data. As 
such, the data model is the blueprint of the organization, and represents an 
effective tool for management to develop and evaluate different policies, 
objeaives, and strategies. 

There are nine basic building blocks defined in IE. Each of which 
is highly dependent on the one beneath it. (Figure 6) The first block. Strategic 
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Requirements Analysis, is the foundation for the success of the methodology, but 
unfortunately, it is often overlooked. It attempts to identify the objectives of the 
organization, and what information is needed for enabling it to accomplish these 
objectives. The next block. Information Analysis, comprises a top-down analysis 
of the types of data that must be kept by the organization, and how they 
interrelate. Identifying these data types is critical because of the premise that 
data structures must remain stable. In the third stage. Data Modeling, the 
detailed logical data base design is created. Here, it is critical that the data be 
structured independent of the processes that will use it. The fourth block. 
Procedure Formulation, identifies events that change or use the data base. These 
procedures ideally should be designed by users, possibly with the aid of fourth 
generation languages and application generators. Block five. Data Use Analysis, 
and block six. Distribution Analysis, prepare the logical data model for conversion 
of the data models and procedures into the physical data base design 
accomplished in block seven. Block eight. Program Specification Synthesis, merges 
the different procedures, documents data changes, and produces functionally 
cohesive program code. Finally, block nine. Application Development Without 
Programmers, represents the ability of users to develop their own applications 
through the use of non procedural languages and capabilities. 
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c. Assessment of Information Engineering 

The stability of data models achieved through the use of IE is a 
major selling point, in that it allows for the creation of flexible, objectives-driven 
systems that meet the current and future information needs of an organization. 
Further, the use of modeling techniques throughout the IE lifecycle, provides for 
rapid feedback for strategic management. Modeling allows management to 
quickly consider the implications of alternative strategies. Additionally, the IE 
lifecycle is an evolutionary process whose formal steps progressively expand and 
enrich the data model and its strategies. Finally, and most important. Information 
Engineering is user-driven. It draws on the expertise of users throughout the 
organization. They design the data model; they design the system; and they 
identify the data and information needed by managemeiU for decision-making. 
The user intensity of IE is one of its primary drawbacks in real-world 
applications. IE requires a large up front commitment from users and 
management in order to provide a solid strategic and conceptual foundation for 
systems development. Without this commitment, the benefits of utilizing IE 
cannot be fully realized. Further, it assumes that users and management 
understand their business and the methodology; neither of which are safe 
assumptions. Thus, training in both areas should be a prerequisite of an IE 
project to ensure that the conceptualization of the data model is accurate. 
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3. IBM’s Business Systems Planning (BSP) 

a. Overview 

BSP is a planning methodology that has been offered as a market 
support program by IBM since the early 1970’s. It was developed from 
knowledge acquired from an internal study, the IBM Corporate Information 
Systems Architecture group, in the late 1960’s. [Ref. 13:p. 48] BSP stresses "top- 
down" enterprise analysis, and an implementation strategy where information 
support is implemented in a modular fashion over time. This ensures that the 
implementation remains consistent with organizational business priorities, available 
funds, and other shorter-term considerations. 

Several steps are involved in a BSP analysis. The first step 
involves establishing the study scope, selecting the study team, and defining 
business objectives. The next step is to define business processes and then 
business data. Data definition is accomplished by identifying critical business 
entities and the data required to manage them. Finally, an information 
architecture, the statement of long-term IS objectives, is defined, reviewed by top 
management, and released. Designer/analysts will use this information 
architecture in the future to build enterprise-based information systems. 
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b. Methodology 

As with Information Engineering, the success of a BSP study is 
highly dependent on top management involvement. As such, an assessment of the 
degree of commitment of the organization to the study should be conducted prior 
to commencement of the study. Alter this assessment, the project team should 
be selected from key management personnel with expert knowledge of the 
enterprise and its functions. Once this is complete, the project team will attempt 
to identify and set objectives for the organization, and then establish a scope for 
the project. This project scope can target a specific area of the organization, or 
cover its entire span. 

Businesses whose activities span multiple functional units tend to gain more 
from a BSP study than those that are more simply structured since BSP 
deals well with complexity. It is designed to identify the requirements for 
data integration across multiple functions. [Ref. 14;p. 14] 

Once the above issues have been dealt with, the project team must 
select and schedule specific personnel to be interviewed, develop a master plan 
for the study, and establish administrative support for the project. Finally, a start¬ 
up meeting, attended by the project team, key management, and other pertinent 
personnel, should be conducted to "kick-off" the study. 

The first step in the actual BSP study process is the definition of 
business processes. Business processes are groups of logically related decisions 
and activities required to manage organizational resources. In order to accomplish 
this step, the project team must first identify the products or services output by 
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the organization, and its supporting resources, such as raw materials, capital, 
personnel, and facilities. Next, business processes relating to these items are 
identified. There may be multiple processes for each one. This initial list of 
processes is then pared down, grouped, and prioritized to reduce inconsistencies 
and redundancies. Finally, these products must be related to organizational units. 
This is accomplished through the development of Process/Organization Matrix. 
This matrix graphically illustrates the degree of involvement of the various 
organizational units in each business process. (Figure 7) There are four possible 
degrees of involvement: major responsibility and decision maker (X), major 
involvement (X), some involvement (/),and no involvement (blank). 

After all business processes have been defined, the project team 
must identify and define business entities, data classes, and the relationship 
between the two. A business entity can be a person, place, or thing, or any 
pertinent item about which data can be collected or stored. Their identification 
serves as a basis for determining the data needs of the organization. Each 
business entity should be broken down to where it can be uniquely identified, and 
carefully described. Next, the business entities are clarified and refined by 
determining data needs, their related business processes, and the relationship of 
both to the specific entities. Determination of the relationship of data to 
processes allows the project team to identify data classes: a category of 
information about a specific entity. Finally, each data class is refined and 
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described completely. There must be no more than one source for each data 
class in order to ensure data integrity. 

After all data classes are defined, the relationship between data 
classes and business processes is established through the formulation of the 
Information Architecture (Process/Data Qass Matrix). (Figure 8) There are three 
types of relationships represented in the matrix: creation (C), where the process 
creates the data class; usage (U), where the process uses the data class; and no 
involvement (blank). The groupings resulting from this matrix can then be related 
to organizational personnel and structure. This gives the organization a logical 
view of who needs and uses specific data and information, and in what processes 
they use them. Finally, data flows between processes are identified, by relating 
processes that create data classes and those that use them. Arrows are drawn 
between the two to create a flow chart of data through the organization. The 
resulting information architecture is the key deliverable of a BSP study. It 
illustrates information flow throughout the organization, and relationships between 
processes and entities. Further, it provides management with the following 
f)ertinent information: [Ref. 14:p. 45] 

1. The project team’s recommendation for long range IS implementation. 

2. The information systems, represented by the blocks or boxes, that form the 
long range plan. 

3. The data controlled by each information system, (read vertically) 
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4. The business processes supported by each information system, (read 
horizontally) 

5. The flow of information between the various information systems, (lines 
and arrows) and thus the flow of information through the business itself. 

From these results, management can determine their current level of IS support, 
determine organizational IS priorities, and decide on current and future 
information resource strategy. 

c. Assessment of Business Systems Planning 

BSP was the first methodology to recognize and emphasize data as 
a corporate resource. As such, it emphasizes the fundamental need for top 
management involvement in the IS planning process. It helps establish lines of 
communication between users, top management, and data processing personnel, 
and confronts management with the importance of dealing with DP issues on an 
organizational level. Further, it develops an enterprise-level information 
architecture, and "objectively deals with the priority issue, identifying areas in 
which the information system resource can best be invested for the overall 
interest of the business at a given point in time." [Ref. 13:p. 49] Finally, it is 
a well documented methodology, it is widely used, and it is widely understood. 
[Ref. 13:p. 49] There are several key weaknesses apparent in the BSP approach. 
First, since the entire process is based on creative analysis and individual 
interviews by the project team, it’s quality is highly dependent on the team’s 









understanding of what they are looking for, where they will find it, and how to 
document it. Second, the structure developed is highly customized, with limited 
transferability or comparability to other study’s structures. Third, the BSP study 
process is a time-consuming and cumbersome process, that really only 
encompasses the planning, organizational analysis, and requirements analysis 
phases of the systems lifecycle. In addition, it is extremely difficult to bridge 
between the planning activity of the study and systems implementation. The 
deliverables of the process, the matrices and displays, are difficult to update, and 
provide no basis for the system’s design. As such, systems developers must take 
the product of a BSP study and then revert back to traditional system 
development techniques. This just adds more unnecessary time constraints to the 
development process. Recently, CASE tools such as KnowledgeWare’s lEW have 
automated portions of the BSP process, speeding it up, but many of the 
weaknesses discussed remain. 

4. Comparison of Information Engineering and BSP 

Both Information Engineering and Business Systems Planning are data- 
oriented, and both recognize the importance of linking information systems 
planning to the strategic objectives of the organization. In addition, both 
methodologies are widely used and well documented. However, Information 
*:^iigineering provides significant benefits to the organization relative to BSP. 
First, IE provides a set of interrelated systems development techniques that span 
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the entire systems lifecycle, from strategic planning to full systems implementation. 
On the other hand, BSP only provides techniques for organizational analysis and 
strategy-to-requirements transformation. It does not provide full lifecycle support. 
Second, IE is a user-driven methodology, whereas BSP is essentially analyst-driven. 
In an IE project, users are fully involved in the development of the data models, 
and throughout subsequent phases of development. BSP studies utilize personal 
interviews to glean information requirements; construction of the Information 
Architecture is accomplished by analysts. Third, whereas IE supports systems 
development through implementation, the deliverables of the BSP process are 
difficult to update, and provide no basis for system design. As a result, the IE 
process is considerably faster over the same lifecycle phases than BSP; a vital 
consideration in today’s IS climate. 
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m. INFORMATION RESOURCE PLANNING IN THE DEPARTMENT OF 

THE NAVY 

A. THE DEPARTMENT OF THE NAVY’S IR PLANNING PROCESS 
The IS p lanning program in the Department of the Navy is a multi-level 
program that seeks to develop an integrated approach and overall framework for 
meeting its overall information requirements. It attempts to align IS planning at 
all levels to the overall strategic objectives of the organization. SECNAV 
Instruction 5230^10, the DON Strategic Plan for Managing Information _aDd 
Related Resources (IRSTRATPLAN), provides a top-down perspective of DON 
information resources as they relate to both tactical and administrative functions. 
In addition, it provides strategies, policies, and guidance, on which DON 
commands can base their IR planning and management efforts, SECNAV 
Instruction 5230.9A the Information Resources (IR) Program Planning guide, 
provides top-down IR planning guidance to DON organizations at the 
departmental, functional sponsor, and component levels. Both documents provide 
a broad foundation on which to structure DON IR planning efforts. 

The DON IR planning program is a continuous process that includes both 
strategic IR planning and IR requirements planning. Strategic IR planning 
requires an analysis of the information support environment internal to the DON 
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and an assessment of the impact of external factors such as technology trends, 
competition, and politics. Top management derives high level IS policies and 
strategies from this analysis, and these provide the basis for IR planning at all 
subordinate levels. Results of the strategic IR planning process are documented 
in the DON Strategic Plan For Information Systems Management . [Ref. ll:p. 5] 

The objective of DON IR requirements planning is to analyze major 
organizational functions, derive their information requirements, and coordinate the 
requirements with the strategic directions and policies promulgated in the strategic 
plan. Both current and future information requirements are assessed, and any 
shortfalls in satisfying those requirements are identified. Tlie informati on 
requirements derived form the basis for project selection downstream at the 
activity level. 

The DON IR requirements planning process begins in January at the 
Departmental level, and continues through April. (Figure 9) In January, 
departmental level functional sponsors document DON-wide requirements for IR 
support needed in major functional areas such as Manpower, Supply, or Safety. 
These requirements are documented in Functional Area Strategic Plans (FASP). 
FASP’s were previously called Functional Sponsor Plans. In February, the FASP’s 
are reviewed by the IR Planning Committee to ensure "appropriate interfaces and 
integration between functional area planning." [Ref. ll:p. 6] The IR Planning 
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Committee should consist of high-level members from commands at the 
departmental and component level, such as the Director, Naval Supjrfy Systems 
Command, or the various Deputy Chiefs of Naval Operation. The FASP’s are 
submitted to the Director, DON Information Resource Management 
(DIRDONIRM) in March. They are presented at the Functional Area strategic 
planning conference, also in March, and are distributed to the cognizant 
component commands. The results of IR planning at this level are documented 
In the DON Information Management Plan (IMP) released in June. 

IR planning occurs at the component level from April until July. 
Component level IR planning "develops a framework for IR support within the 
component headquarters and all subordinate organizations. Emphasis is on 
supporting the component’s mission and functions within the context established 
by departmental strategic and long-range plans." [Ref. ll:p. 6] The results of the 
component level IR planning process are documented in Component Information 
Management Plans (CIMP). In mid-August, the CIMP’s are presented to the IR 
Planning Committee at the annual IR Planning Conference. Each CIMP is then 
distributed to all organizations having a funding or other management 
responsibility for planned actions. 

Throughout the rest of the year, IR planning and management occurs at the 
cognizant activity level in accordance with the Planning, Programming and 
Budgeting System (PPBS) and Life Cycle Management (LCM) processes. The 
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objectives promulgated in the CIMP or FASP will, if approved for development 
or acquisition, be further refined in project plans, which in turn, form the basis 
for initiating the LCM process. 

B. ASSESSMENT OF DON IR PLANNING PROCESS 

On paper, the DON IR planning program appears to be comprehensive and 
effective. On the other hand, several habitual internal management problems 
continue to hinder these efforts. First, top DON management, including IS 
management, suffers from an insufficient level of expertise on key computer- 
related issues. Misperceptions as to what Information Resource Management is, 
why it is required, and what organizational structure is required to accomplish it, 
cause a lack of direction concerning IR planning at top DON IS management 
levels. This manifests itself in a deficiency of specific top-down guidance from 
DIRDONIRM and NAVDAC, which hampers the annual planning efforts of 
subordinate levels. The key to successful IR planning at all levels is for top 
management to "clearly define at any point in time exactly those factors that are 
crucial to the success of his particular organization in the period for which he is 
planning." [Ref. 15 :p. 127] Similarly, NAVDAC and the DONIRM staff have 
been unable to provide the assistance and training required by component and 
subordinate activities to build their own IR planning staffs. Their lack of 
expertise on IRM-related issues prevents them from providing the proactive 
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leadership required for effective IR planning, and limits them to a review role in 
the planning process. The ability to provide detailed critiques of the ClMP’s and 
FASP’s, and to ask hard, probing questions of both components and resource 
sponsors, is vital to effectively manage the DON IR planning effort. In order to 
reach the knowledge level required for effective management of the IR planning 
process, a comprehensive education program on IRM and IR planning issues 
should be established. The training program should reach all personnel with 
management and funding responsibility in this arena, and cover all facets of 
Information Resource Management including planning and Data Administration 
issues, and strategic development methodologies such as Information Engineering. 
A related issue which has adversely affected the effectiveness of IR planning and 
IRM, is the shortage of computer-literate officers at all levels, resulting from the 
failure to create a competitive career path in this area. The failure to effectively 
utilize officers with Masters-level education in Computer Systems Management, 
Telecommunications, and Computer Science, has created a significant management 
void in these fields, and an important barrier to effective IR planning. A second 
internal factor hindering the IR planning process has been the lack of 
commitment to the process by top management at the resource sponsor and 
component levels. This is evidenced by their attendance record at the annual 
planning conferences, and their level of participation at the meetings. Generally, 
the senior managers attend the conferences for their briefs only, and then turn 
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over responsibility for attendance to second tier management. Second tier 
management is usually only interested in what DIRDONIRM has to say, and not 
on broader issues that may influence planning at their organization. In addition, 
they are generally unprepared, and are incapable of asking or answering important 
questions. As a result, integration issues are not discussed, and therefore not 
planned for at subordinate levels. This lack of top management commitment is 
partially due to their lack of ease regarding IRM issues, but also to 
misperceptions as to the strategic importance of the information or data resource 
to the organization. They see no immediate benefits from their efforts, and as 
such, view the IR planning process as a significant resource drain and paperwork 
hassle. Further, due to the current budget climate, top management commitment 
is driven by cost considerations, and therefore, is not focused on long range 
planning issues. 

Other internal fartors affecting IR planning in the Department of the Navy 
are the result of deficiencies in the process or the documentation that governs it. 
First, the IRSTRATPLAN has been updated three times since its inception in 
1987. The document has developed into a forum for top DON management to 
react to changing information requirements, and therefore is contradictory to what 
the dociunent should be accomplishing. The IRSTRATPLAN should serve as an 
IS Master plan with a five to ten year planning horizon. It should be a forward 
thinking and proactive document that serves as the foundation for IR planning. 
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and should not be updated or modified on an annual basis. It should only be 
updated as major changes in technology or in the various missions and objectives 
of the Navy occur. Second, the functional sponsor planning process has been 
yielding information requirements and policies that fail to provide an integrated 
view of what must be accomplished at the component level to meet their needs. 
This is due to two reasons. First, in most cases, the Functional Area Strategic 
Plans are being written by the Systems Commands (SYSCOM) or components 
acting as Central Design Agencies (CDA), that are to use them as a basis for 
their own planning process. As a result, they don’t correlate plans and budgets 
well, and worse, they fail to address broad issues such as standardization and 
integration. Second, the SYSCOM’s and CDA’s tend to write the FASP’s and 
CIMP’s in a manner that justifies their own existence. Since they are writing 
their own planning guidance, there is no top-down pressure to streamline or 
improve the planning and development processes in their organizations. Finally, 
the DON IR planning process is hindered by significant time constraints. 
Requirements planning at the functional sponsor level is constrained to three 
months, while the more comprehensive component planning process is limited to 
two months. These are highly unrealistic constraints for effective planning and 
policy making. However, since the FASP’s are written in large part by 
component level organizations, and since the requirements and policies they 
document are relatively static, it is recommended that the functional area strategic 
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planning process be limited or done away with. By doing so, the importance of 
the IRSTRATPLAN as a strategic and tactical planning document would be 
increased, as would the length of time devoted to IR planning at the component 
level. IR Planning in the Department of the Navy has been hindered by two 
external factors as well; today’s unstable budget climate, and inefficiencies in the 
life Cycle Management (LCM) process. As a result of todays highly unstable 
budget climate, and the significant cuts in funding for ADP that have been 
incurred by the Department of Defense, IR planning currently involves running 
from budget issues. Planning has become resource-driven in that it is aimed at 
protecting what resources and funding assets that have already been accumulated. 
In addition, vertical cuts and temporary scalebacks in programs have made it 
impossible for management to develop systems in accordance with their plans. 
Finally, budget constraints have adversely affected DON efforts to establish 
standards. The inability to establish DON-wide standards will hinder any efforts 
to implement Administration, or to move towards an integrated overall IS 
architecture. 

The second external factor hindering DON IR planning efforts is the 
inefficiency of the Life Cycle Management process when applied to ADP 
acquisition and development. The process affects IR planning and management 
by significantly slowing down the process of procurement and development of IS 
resources. Continual budget justification at each milestone of the process make 
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the IS plan difficult to execute as envisioned, and mires the project manager in 
a continuous paperwork nightmare. Each LCM milestone should signal the 
transition to the next stage in the development of the program, but due to 
continual budgetary second guessing, the process has become a continuous string 
of milestones, none of which move the project ahead. The only ways to solve 
this problem are to grant the project manager with increased authority, 
accountability, and time in position to allow himself to make procurement 
decisions, to significantly accelerate the development process through the 
employment of CASE technology, or to alter the LCM process. 

In its present configuration, the LCM process is geared towards multiple 
year systems development processes. The availability and desirability of 
progressive systems development methodologies such as Information Engineering 
make the requirement for a modified LCM process for ADP vital. The ability 
of Information Engineering to accelerate the entire systems lifecycle will be 
defeated by the continual budget justifications required by the current LCM 
process. Total lifecycle approval should be given up front for a program utilizing 
Information Engineering, as this would facilitate a total commitment, with all 
required resources, to the IE process. Deferring reevaluation of the program until 
System Decision Paper (SDP) IV at approximately the two year point would be 
optimal. 
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C. CORPORATE INFORMATION MANAGEMENT (CIM) 

The Corporate Information Management (CIM) initiative was launched by 
DoD Comptroller Atwood on 4 OCT 89 in response to problems found in the 
recent Defense Management Review (DMR). The initiative represents a move 
to consolidate and standardize DoD information systems development and 
management. Specifically, the CIM initiative calls for the following: 

1. Implementation of DoD-standard information systems in six fimctional 
areas: Civilian Personnel, Pay, Inventory Management, Warehousing, 
Accounting, and Contracting by 1995. 

2. Immediate freeze on new systems, and spending on systems imder 
development in the above functional areas. 

A separate but related issue, prompted also by the DMR, is the consolidation of 
Central Design Agencies (CDA) and Data Processing Installations (DPI) into tri¬ 
service organizations called Information Technology Facilities (ITF). The impetus 
for these changes is the need to reduce redundant systems in these functional 
areas. As an example, it was stated that there are twenty-six separate payroll 
systems throughovt the DoD. In addition, it was stated that DoD organizations 
spend upwards of $4 billion annually on development, maintenance, and ^ 
modernization of information systems. The DoD comptroller estimates that this 
initiative should result in total savings of $4.3 billion from FY ’91 to FY ’95. As 
a result of this initiative, the DoD has line item reduced DON ADP budgets, to 
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take into account the anticipated cost savings from CIM. This equates to $327 
million annually over the next five years. 

The CIM initiative holds significant implications for DON IRM and IR 
planning efforts. Most importantly, the directed spending freeze has made the 
interim and target architectures on systems currently under development 
unattainable. Second, it has superceded, although not officially, the DON IR 
planning process, as a result of the spending freeze, and the pending consolidation 
of CDA’s and DPI’s. Planning for new systems will continue, although existing 
systems must suffice. 

The initiative calls for the formation of two CIM study groups to study the 
issue, and to develop recommendations for DoD-standard systems. The first, the 
Executive-level group, will report directly to the DoD Comptroller, and will be 
comprised of senior DoD and industry officials. The second group, at the 
Functional-level, will report to the Executive level, and will be made up from 
experts in the six functional areas listed above. The groups have been given a 
six month to two year window in which to develop functional descriptions (FD) 
for systems in these areas. From there, they will choose the existing system that 
most closely matches the FD, and then will re-engineer the system to meet tri¬ 
service needs. The current plan is to utilize a "structured approach" such as BSP 
as the front-end planning tool, and KnowledgeWare’s Information Engineering 
Workbench (lEW) as the back-end tool. The prospect of using an Information 
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Engineering-based CASE tool for the study was proposed, and is under 
consideration. Its use would definitely facilitate the process, because of its strong 
data orientation, and its ability to facilitate rapid development of a prototype 
system. Before a tri-service system can be developed, data structures must be 
standardized to meet the needs of all three services. The use of functional 
descriptions to determine requirements would base systems development on a 
process-oriented foundation. Since all three services have substantially different 
processes and needs, this would create a highly unstable basis for a standard 
system. In addition, the development of funaional descriptions, supplemented by 
BSP, would be a slow, tedious process in comparison to utilizing automated IE. 
Finally, the user involvement inherent in the IE development process is highly 
desirable when building a standardized system such as those proposed, because it 
would facilitate communication between the services, and would promote a sense 
of commitment to the process. 
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IV. COMPARING THE INFORMATION ENGINEERING CASE TOOLS 


A. USE OF INFORMATION ENGINEERING AND CASE IN THE 

DON 

It is imperative that DON management employ Information Engineering to 
facilitate its IR planning efforts, "Information Engineering provides the discipline 
to ensure that,..(the DON)...avoids multiple, incompatible, non-integrated systems 
that meet short term needs, but which result in significant data integration 
problems and costs over the long run." [Ref. 16:p. 78] It is an effective 
implementation vehicle for IRM, and represents a formidable weapon for dealing 
with the IR planning problems currently encountered by the DON. IE provides, 
as one of its major deliverables, a highly stable data model. This data model 
provides management with some important advantages. First, it facilitates 
management’s ability to adapt and update the system to meet changing functional 
requirements, because it is data-oriented. Second, it provides DON management 
with a flexible framework upon which one development effort can be based on 
another. Finally, it provides a rigorous logical design which provides increased 
control and integrity, and decreased redundancy, in the physical design. 

IE serves as an effective tool on which to base DON standardization efforts, 
because the data model has the ability to incorporate diverse and complex 
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functions under an integrated architecture. Top DON management has the 
perception that the development of an overall Navy-wide IS architecture, and the 
planning and analysis tasks that must accompany it, are too complex for the 
application of IE. This is unfortunate, because Information Engineering is ideally 
suited for strategic and IR planning and systems development in complex 
organizations, because it models the organization independent of its multiple, 
diverse functions and procedures. As a result, it is capable of integrating 
disparate management issues and information requirements into a single 
consolidated architecture. The use of Information Engineering in the Department 
of the Navy would significantly reduce the time required to design and field 
information systems, and would ensure the most efficient use of management’s 
time in planning for and managing the development process. By providing a rigid 
structure on which to base IR planning, analysis, and design, IE provides the 
discipline necessary to significantly accelerate the development process. It allows 
this acceleration, while improving the consistency and completeness of the design 
relative to traditional methods. Top DON management would experience the 
results of their efforts through faster systems implementation, reduced 
maintenance costs, improved project management, and an overall reduction in the 
applications backlog currently plaguing the organization. 

Finally, the utilization of IE for IR planning and development would protect 
ciurent investments and funding by helping management clearly and accurately 
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determine and prioritize its information needs. A clearly defined, well integrated, 
and proactive IS plan would go far in improving the credibility of the Navy’s IRM 
efforts in the eyes of Congress. The result could be a significant improvement 
in the funding climate. 

B. CASE TOOLS SUPPORTING INFORMATION ENGINEERING 

The Department of the Navy has utilized multiple tools for automating 
various phases of the systems lifecycle. Three tools, in particular, have enjoyed 
widespread use: Information Engineering Systems Corporation’s (lESC) USER: 
Expert Systems; Texas Instruments’ Information Engineering Facility (lEF); and 
KnowledgeWare’s Information Engineering Workbench (lEW), These products 
were selected for review in this thesis because they are the most widely used in 
Department of the Navy applications, and because they have associated 
themselves with the Information Engineering methodology, either as a whole, or 
in part. In addition, lESC holds an umbrella contract with the Naval Data 
Automation Command (NAVDAC) for IE methodology training, technical support, 
and automated suppxrrt tools usage. 


1 
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1. lESC’s USER: Expert Systems 


a. Overview 

Information Engineering Systems Corporation was founded by Mr, 
Clive Finkelstein, co-developer of IE, in the early 1980’s. In 1984, lESC released 
USER: Expert Systems, an expert system and CASE product, which automates the 
Information Engineering methodology. Its support extends from strategic planning 
to the generation of computer applications that support those plans. Mainframe, 
mini, and micro computer applications are supported by the product. The 
integrated software package supporting the product provides a class 4 expert 
design dictionary, Level 2 expert modeling support, and Level 2 active 
documentation. Appendix A describes each of these software support tools in 
more detail. 

USER: Expert systems provides expert systems support to strategic 
development of information in five phases, using IE: 

1. Analysis Phase 

2. Design Phase 

3. Build Phase 

4. Prototype Phase 

5. Implement Phase 


58 







lESC maintains that significant cost savings and dramatic gains in productivity can 
be achieved using USER: Expert Systems to automate these phases. Further, 
since the resultant systems were designed extensively by users, their ability to 
meet all information requirements will be enhanced, and they will be more closely 
aligned to the strategic requirements of the organization. 

b. Methodology 

Information Engineering, as practiced by lESC, is composed of 
three major stages: Analysis, Design, and Generation. (Formerly called Discovery, 
Integration, and Implementation, respectively) Each phase is made up of a 
number of stages. (Figure 10) 


(1) Analysis Phase. In the Analysis phase, users, with the aid of 
the project team, use strategic and tactical statements derived early in the phase 
to identify and define data and the information derived from the data required 
at the strategic and tactical management levels of the organization. It is composed 
of the following stages and steps: [Ref. 5:p. 230] 


1. Project Scope Stage: 

-Identifies the project area 

-Identifies pertinent personnel, including a project leader, and obtains 
management authorization and sponsorship 
-Establishes plans, tasks, milestones, and funding 

-Identifies strategic and tactical statements to be used as input. These 
statements are derived through either formal strategic planning involving 
top management, or through informal planning sessions with lower level 
management. Top management input is received through review of the 
input of the lower levels. 
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Figure 10. lESCs Information Engineering [Ref. 5;p. 222] 































-Trains project personnel in strategic modeling (for top management) and 
tactical modeling (for operational management) 

2. Strategic Modeling Stage: 

-Identifies and clarifies the mission and purpose of the organization 
-Sets strategic directions with appropriate management 
-Analyzes the strategic statements and directions for the future derived in 
the Project Scope phase 

-Broadly identifies strategic data and operational segments that generate 
tactical data on which the strategic data is based 

3. Strategic Objectives Modeling: 

-Reviews goals and objectives, concerns and issues, and policies 
implementing those goals, objectives, and issues 
-Determines performance criteria 

-Identifies strategic data for measurement of performance criteria 
-Establishes performance ranges and controls for decision early warning 

4. Strategic Refinement: 

-Progressively refines strategic data using a formal approach 
-Establishes standard terminology and expert rules at the strategic level 
-Produces strategic data models representing a strategic blueprint for 
management and a basis for tactical modeling 

The strategic modeling stages are carried out by responsible senior 
management in the project area. Goals and objectives, concerns and issues, 
and relevant policies identified above are used to classify strategic data for 
input into the strategic data model. This model is used to plan the 
detailed tactical modeling stage. 

5. Tactical Modeling Stage: 

-Identifies the tactical environment with middle and operational managers 
-Expands the strategic data models through analysis of markets, services, 
products, and channels 

-Identifies detailed tactical data of interest to middle and operational 
management, and data used to derive strategic data of interest to top 
management 

6. Tactical Objectives Modeling: 

-Examines management objectives at various levels in the project area 
-Progressively refines objectives, strategies, and tactics 
-Further refines strategies for later definition of expert rules 
-Identifies data neck to manage achievement of objectives 
-Identifies exception reports and decision triggers at the tactical level 
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7. Tactical Refinement: 

-Progressively refines tactical data using a formal approach applied against 
each functional area separately 

-Establishes standard terminology and expert rules at the tactical level 
-Produces tactical data models which are a detailed blueprint of the 
organization 

Much detail of the project area’s data resource is identified and refined in 
the tactical modeling stage. The functions of the stage are analogous to 
the strategic stage, except on a more detailed level. In most, but not all 
cases, the tactical data model is used as input for operational modeling. 

8. Ciurent Systems Modeling; 

-Used with tactical modeling for current manual or automated systems, or 
packages, needed for the future 

-Formally cross checks data presently used in existing source documents, 
reports, ledgers, comPuter files etc. against tactical data models 
-Discards current data not needed for the future 
-Includes data for the future that was overlooked in previous stages 

9. Operational Objectives Modeling; 

-Examines operational objectives in the project area 

-Identifies data neck to manage achievement of objectives 

-Identifies exception reports and decision triggers at the operational level 

10. Operational Refinement; 

-Progressively refines operational data for each functional area defined 
-Establishes standard terminology and expert rules for the operational level 
-Produces operational data models for day-to-day operation of the 
organization 


Current systems modeling does not require the same level of 
expertise about the operation of the business as the previous stages. It serves as 
a formal cross check of the strategic and tactical data models to ensure that all 
fundamental data is identified. It can generally be carried out by IS personnel 
or systems analysts using existing source documentation. 
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(2) Design Phase. The design phase is an automated phase using 
the Expert Design Dictionary. Although it can be applied after the analysis 
phase, it is most effective if it is applied concurrently with strategic and tactical 
modeling and refinement. In strategic design, the strategic data identified in the 
Analysis phase is entered into the Expert Design Dictionary; a tool that fully 
automates the Information Engineering process, and checks for data consistency, 
consistency across data models. It automatically combines common data into an 
integrated strategic model. The process is analogous for tactical and operational 
design. Tactical and operational data are entered into the Expert Design 
Dictionary concurrently with derivation of the models. The models are analyzed, 
and common data is then combined into integrated tactical and operational 
models. 


c. Generation Phase 

The integrated strategic, tactical, and operational data models 
output from the design phase are utilized as the design blueprint for the final 
phase: Generation, The Generation phase defines detailed implementation 
strategies for each part of the integrated data models. These models may 
represent the conceptual basis for both manual and automated systems. Expert 
design software automatically restructures the integrated data models in the 
dictionary into submodels specific to each application, for implementation. 
Software, hardware, and communications facilities, and the physical design of the 
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application are determined. Reports, and procedures are defined as well. The 
resultant submodels provide a language-independent interface to information 
systems, and provide a direct input to the automatic generation of information 
systems. 


d. Training and Workshops 

The success of an Information Engineering project is directly 
related to the commitment and training of users. lESC provides a comprehensive 
training and quality assurance program to supplement its CASE product. This 
program is composed of six major workshops, plus executive and top management 
overview presentations. The education program is designed to enable the project 
team to be self-supporting as soon as possible, ensuring maximum projea 
concurrency and high productivity. Periodic quality assurance consulting ensures 
a consistently acceptable product. The six workshops are described below: 


1. Introductory Workshop: 

-Definition of project boundaries and scope 
Jevelopment of preliminary strategic and tactical data models 
-Completion of management questionnaires (2 weeks prior) 

-Review and prioritization of preliminary models by top management 
-Identification of personnel for later stages 

2. Strategic Modeling Workshop; 

-Strategic data model developed from preliminary models 

-Review of strategic data model by top management to identify priority 

tactical areas 
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3. Strategic Management Workshop; 

-Development and refinement of relevant policies, objectives, and strategies 
-Identification of critical success face and measures of effectiveness 
-Strategic gap analysis 

-Management review of refined strategic model and strategic plans 

4. Tactical Modeling Workshop: 

-Extension of strategic data model into several tactical data models 
-Management review of tactical data model to identify priority areas 
-Identification of personnel for involvement in later phases 

5. Operations Modeling Workshop; 

-Extension of tactical models of priority areas into operational models 
-Detailed definition of the specific operational system 
-Management review 

6. Implementation Workshop; 

-Operations modeling and refinement of priority operational systems 
-Design and implementation of applications with aid of PROLOG Design 
Knowledge Base. 


Figure 11 illustrates a typical project plan, with scheduling of 
education, modeling, refinement, and implementation. Note that the entire 
process lasts approximately six months on average. Modeling and refinement of 
models and applications is an iterative process throughout the project schedule. 


e. USER: Expert Systems Software Product Description 

The USER: Expert Systems software package represents an array 
of expert systems that automate the Information Engineering methodology. This 
software assumes that the user has knowledge of the business, but no signifi¬ 
cant computer experience. The software was designed primarily for use on 
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microcomputers since they are the most accessible to the business user. Hardware 
requirements such as memory, performance, and output specifications, for USER: 
Expert Systems are listed in Appendix B. The software package comprises the 
following expert systems:^ 


1. USER: DATA is an Expert Design Dictionary that is composed of a Class 
4 Expert Design Dictionary and a Strategic Planning Dictionary. It 
provides support to both users and analysts, and automates the Analysis 
and Design phases of IE. It allows clear defini:’ ^n of the strategic data 
resource, and the automatic integration of common data throughout the 
organization. 

2. USER: PROJECT is an Expert Project Management System that supports 
the Generation phase of IE. It supports the identification and progressive 
implementation of subject data bases, and automatically derives an 
implementation plan from the data defined in the Expert Design 
Dictionary. Finally, based on the defined business strategies, it prioritizes 
the subject data bases for future development efforts. 

3. USER: GENERATOR is an Expert Development System that supports the 
Generation phase of IE. It automatically generates a PROLOG taowledge 
base of the strategic and tactical data models, and supports the design of 
screen forms and reports. Further, it automatically generates the data base 
creation statements required for automatic installation of the subject data 
bases on micros, minis, or mainframes using a target data base management 
system (DBMS). These data bases and applications can be prototyped on 
a microcomputer using USER: SQL, a full implementation of DB2 SQL 
packaged as a part of USER: GENERATION. 

4. USER: PROCEDURES is an Expert Logic Refinement System supporting 
the Generation phase. It automates procedure modeling, and automatically 
derives procedures and programs for processing the data defined in the 
models. A detailed representation of this processing logic is generated 
automatically using graphical procedure maps and structured English 
statements. 


' lofonnatios for this lectioii was drawn from Ref. 16;pp. 16-19. 
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5. USER: IMPLEMENTATION provides a series of Expert Systems 
Migration products that are designed to translate systems developed with 
USER: GENERATOR and USER: PROCEDURES for migration to 
minicomputer and mainframe hardware, operating systems, DBMS 
products, and languages independent of the USER: Expert Systems software 
environment. 


The following expert systems facilities support the software 
products described above, in order to provide full capability to automate the 
Information Engineering process: 


1. USER: ADMIN is an Expert Systems Administration Facility supporting 
all USER: Expert Systems products. It automatically verifies the integrity 
of the Expert Design Dictionary, and provides automatic repair when 
applicable. It supports multiple Design Dictionaries for multiple projects, 
and provides a menu-driven DOS shell for access to MS-DOS/PC DOS 
facilities. 

2. USER: PLOTMASTER is an Expert Data Mapping Facility offering a 
Level 2 expert data modeling capability which is fully integrated with the 
Expert Design Dictionary. 

3. USER:UEF is an Expert Design Dictionary Expert Facility that 
automatically generates the PROLOG knowledge base with USER: 
GENERATOR, and acts as an open architecture export facility. 


These software tools and facilities provide comprehensive support 
for strategic planning, data modeling, and system design activities, and represent 
a highly effective front-end CASE tool. 
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f. Assessment of USER: Expert Systems 

USER: Expert Systems provides the most comprehensive front-end 
support of the IE process of the three CASE workbenches discussed. It is fully 
data-oriented; relationships and restrictions between data are used to group data 
into potential information systems. Further, it is the only product on the market 
today that normalizes data to Fifth Normal Form (5NF). No other product 
normalizes data past Third Normal Form. "An entity is in fifth normal form 
if it is dependent on other occurrences of the same entity or entity type". 
[Ref. 18:p. 9.13] In other words, 5NF is indicated by the presence of a recursive 
relationship. Normalization to 5NF is particularly important to the design of 
expert business systems because it enables intelligence to be built into the data 
model. Further, it permits the representation of logic intrinsic to the data model, 
based on the structure that exists between related occurrences of a specific data 
entity. [Ref. 5:p. 141] Thus, it allows the representation of highly detailed, 
intricate interrelationships between data elements, such as the ability to define 
technical substitutes in an inventory management system, or to optimize routing 
of deliveries in a distribution system. 

Whereas most CASE products seek to improve the productivity 
of programmers and the software development process as a whole, USER: Expert 
Systems is oriented towards management and users. lESC is essentially a training 
and technical support organization using its CASE tool for support. As such, it 
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provides an outstanding training tool for understanding the business and its 
functions. The product itself is highly user-driven; modeling and normalization 
are performed by the user under the guidance of lESC representatives. Further, 
lESC conducts a series of workshops which supplement both training and systems 
development efforts. This user-oriented approach has the advantage of promoting 
user acceptance, as well as helping to identify strengths and weaknesses in the 
organization. Interviews, questionnaires, and observation often only identifies 
problem areas in an organization. Using lESCs user-driven process, users are 
able to identify and assess not only problem areas, but what the organization is 
doing right. One drawback of the product is that the success of any project using 
lESC support is directly related to the amount of user involvement and 
management support received. In addition, a commitment by management to take 
advantage of the training support provided by lESC is vital. lESC’s first U.S. 
Navy project, providing Information Engineering support to NAVSEA’s 
Comptroller Directorate [SEA 01), failed due to inadequate training of users and 
a lack of top management commitment to the project. [Ref. 16:p. 96] 

USER: Expert Systems is a highly effective "front-end" tool, 
providing comprehensive support for strategic planning, methodology and business 
training, strategic data modeling, and tactical data modeling. It falls short 
however, in support of "back-end" processes such as process modeling and code 
generation. Further, it does not support a centralized data dictionary, capable of 
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fully and automatically integrating data structures from multiple workstations. 
Both of these items are "in the works", with the most likely solution being the 
integration of USER; Expert Systems with an established back-end tool such as 
MAGEC, and CASE integrator such as ASYST. Finally, the software is not 
always "user-friendly", as much of it is still immatme. 

2. Texas Instruments’ Information Engineering Facility (lEF) 
a. Overview 

Texas Instruments (TI) began automating Information Engineering 
for internal use in 1983. As TI continued to develop the process, it recognized 
the practicality, and potential marketability, of using automated IE for applications 
development. The Information Engineering Facility (lEF) was the result. lEF 
consists of four integrated toolsets which together, automate the entire 
Information Engineering process, from planning, through analysis, design, and code 
generation. lEF implements the major IE diagrams, passes information 
automatically between diagrams, performs consistency checks and transformations 
between stages, and finally, writes the source code. Three of the four toolsets. 
Planning, Analysis, and Design, are PC-based, and work from information residing 
in local encyclopedias. The fourth toolset, a Code and Data Base Generator, 
resides on a mainframe, as does the heart of the system, the Central 
Encyclopedia. The Central Encyclopedia, a sophisticated DBMS and control 
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system, acts as a central repository for business models under construction, and 
as a project management system. Figure 12 illustrates the lEF environment. 


b. Methodology 

The lEF is based on James Martin’s variant of Information 
Engineering. It models the business rather than isolated systems, and views the 
development of information systems in terms of three components; business Data, 
business Activities, and Interaction between the two. Information Engineering 
incrementally refines each of these three components, and then integrates them 
to form executing applications. This refinement takes place in seven stages, with 
each of the three components becoming more detailed than in the preceding 
stage. The seven stages and their associated objectives are: [Ref. 19:pp. 35-39] 


1. Information Strategy Planning (ISP): 

-Assess the information requirements of the organization 
-Construct an Information Architecture to meet those requirements 
-Construct a Business System Architecture to support implementation of the 
Information Architecture 

-Identify the Technical Architecture required to support the Business 
System Architecture 

-Develop a Mission Statement, and identify pertinent environmental factors 
-Present findings to top management for evaluation and action 

2. Business Area Analysis (BAA): 

-Fully identify and define the data needed by the business area 

-Identify and define the business activities of each business function 

-Define the data required for each business activity 

-Identify the necessary sequence of business activities 

-Define how each business activity affects the data 

-Produce an implementation plan for the Business System Design (BSD) 

stage by prioritizing and integrating defined business systems 

-Develop data, activity, and interaction models for each business area 
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Figure 12. The lEF Environment (Ref. 19:p. 27J 
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3. Business System Design (BSD): 

-Define human-to-computer interactions required to carry out the previously 
defined business activities 

-Refine and describe the business system required by the organization 
-Develop procedure and data views of each business system 
-Develop screen and report layouts 

4. Technical Design (TD): 

-Tailor the business model to a specific DBMS 
-Determine environment-specific implementation details 

5. Construction; 

-Build application programs from the integrated model prepared previously 
-Build application data bases 

-Build additional environment-specific constructs required for program 
execution 

-Develop screen definitions based on layouts produced earlier 

6. Transition; 

-Develop a Transition Plan to include the following issues: training, 
installation, final acceptance testing, cut-over, and post-implementation 
review 

-Install the application system and data structures in a production 
environment, based on Transition Plan 

7. Production; 

-Quality monitoring and performance measurement 


c. Workshops and Training 

Texas Instruments provides training workshops that are 
recommended prerequisites to using the toolsets they support. These workshops 
are oriented more towards establishing user proficiency with the tools, than 
towards methodology training. An ISP workshop is provided to train members 
of an "Information Strategy Planning Team," made up of management personnel. 
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in the operation of the Planning toolset. Prior to utilizing the Analysis toolset, 
a BAA workshop is recommended to provide the education necessary to 
effectively conduct the Business Area Analysis phase and use the toolset. Finally, 
TI provides a BSD workshop and a Data Structure Diagram workshop as 
prerequisites for using the design toolset. It is highly recommended that cognizant 
personnel attend the workshops in order to ensure that they are fully versed in 
the operation of the toolsets, processes, and diagrams they will be utilizing. 

d. lEF Software Product Description 

The Information Strategy Planning stage is supported by the 
Planning toolset, and to a lesser extent, by the Analysis toolset. During the ISP 
stage, these toolsets assist the ISP team in developing a framework on which to 
base the subsequent analysis and design of the potential application. They 
provide support for ISP through the use of the following set of diagramming tools 
and editors:^ 

1. Indented List Editor: specifies organizational hierarchies and business 
activity hierarchies. 

2. Matrix Processor: automatically performs matrix clustering and affinity 
analysis to help segment the business into business areas and business 
systems. 

3. Entity Relationship Diagramming tool: represents the information used in 
the business, including high-level entity types. Produces a high-level Entity 
Relationship Diagram. 


^Software product desaiptioos in this lectioD drawn from Ref 3M1. 
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4, Process Hierarchy Diagramming tool: records business activities in a tree 
structure. Produces a high-level Function Hierarchy Diagram. 

5. Process Dependency Diagramming tool: records interdependencies between 
business activities. Produces a hjpb-levei Funaion Dependency Diagram. 

During the Business Area Analysis stage, analysts utilize the 
Analysis toolset to work with business functions and entity types grouped into 
business areas. The lEF will automatically check the resultant Business Area 
model for completeness and consistency throughout this stage. The following lEF 
tools support the BAA phase: 

1. Entity Relationship Diagraming tool: represents facts about business data, 
depicts relationships between entity types, and details attributes of entity 
types. 

2. Entity Hierarchy Diagramming tool: partitions entity types into entity 
subtypes. 

3. Process Hierarchy Diagramming tool: records business activities in a 
hierarchical fashion, subdivides fimctions into processes, and defines process 
information views of entity types. 

4. Process Dependency Diagramming tool: records the interdependencies 
between processes, identifies events that trigger processes, and depicts 
information flows from objects outside the business area. 

5. Process Action Diagramming tool: specifies the detailed logic of processes, 
and performs process stereotyping on entity types. 

In the Business System Design phase, the lEF automatically 
transforms BAA-level processes, dependencies, and information views into BSD- 
level procedures, dialog flows, and data views. During this phase, the lEF 









automatically checks the business system model for consistency and completeness, 
and transforms BSD-level entity types, attributes, and relationships into Technical 
Design (TD)- level records, linkages, and fields. The following tools support the 
BSD phase: 

1. Dialog Flow Diagramming tool: defines procedure boundaries and dialog 
flows, binds processes to procedures, specifies linkages, and defines the 
commands and states that trigger these linkages. 

2. Screen Design tool: designs screen layouts associated with procedures. 

3. Procedure Action Diagramming tool: specifies the detailed logic of 
procedures, and automatically transforms and synthesizes BAA action 
diagrams into more highly detailed BSD action diagrams. 


The Technical Design phase requires little human intervention, as 
the lEF automatically transforms previously defined data diagrams into Data 
Structure Diagrams, Both the Design and Construction toolsets support this 
phase. During the TD phase, the lEF automatically checks the business system 
model for consistency and completeness, and prepares the TD-level records, fields, 
and linkages for transformation into data bases during Construction. The 
following tools, residing on the mainframe, support the this phase: 

1. Data Structure Diagramming tool: optimizes data base transformation. 
Pictorial representation of the physical data base layout. 

2. Load Module Packaging Panels: details packaging of procedures into 
execution units, and specifies interfaces to external programs and data 
bases. 
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Finally, in the Construction phase, the lEF writes 100 percent of 
the source code in the target programming language. The lEF can generate 
applications to run under IMS DC/DB2, C1CS/DB2, or TS0/DB2 in the IBM 
MVS environment. The following mainframe-resident tools support the 
Construction phase: 

1. Data Base Generation Panels: start the automatic generation of data 
definition language (DDL) statements. 

2. System Generation Panels: initiate COBOL source code generation and 
compilation, and link/edit. 

3. Interactive Diagram Testing Panels: test application screens, run consistency 
checks, and ensure system logic runs correctly. 

The lEF Central Encyclopedia is the heart of the product, and 
serves as an information repository and project management system for all 
systems currently under development. Data structures, diagrams, structured 
specifications, and report and screen layouts all reside in the encyclopedia. The 
following features of the Central Encyclopedia support the coordination of large 
IS development projects: 

1. Model sharing and distribution 

2. Actual and trial mode! merging 

3. Administrative and statistical reports 

4. Multiple level security access 

5. Support of multiple projects or workstations simultaneously. 
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Figure 13 presents a summary of lEF automated support of the Information 
Engineering process. Appendix C provides further product specifications and 
hardware requirements. 

e. Assessment of the Information Engineering Facility 

Texas Instruments’ Information Engineering Facility (lEF) provides 
full support of the entire IE process from planning through code generation. It 
uses sophisticated diagramming techniques to supplement planning, designing, and 
implementing application systems. These diagrams are fully integrated between 
each other and the business model through the mainframe-based Central 
Encyclopedia. The Central Encyclopedia is the heart of the system, and is a 
major advantage of the lEF. It provides for project coordination, consistency 
checking, and model sharing, as well as providing artificial intelligence-based 
inferencing rules that enforce synchronization between stages. 

Each lEF toolset uses a local encyclopedia, which serves as a 
subset of the Central Encyclopedia, and is fully integrated with it. In addi¬ 
tion, the lEF provides full transformation between toolsets and stages to ensure 
the consistency and completeness of the business model. With the exception of 
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Figure 13. lEF Automated Support [Ref. 19:p. 40] 
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Planning , these toolsets can be used as stand alone CASE tools as well, although 
this would undermine the IE process. 

The lEF supports process modeling and data modeling in all 
phases, a feature not present in lESC’s product. Process modeling supplements 
the IE process by representing activities, procedures, and procedure steps in 
diagrammatical form. This allows analyst to view the business from both views: 
data and activities. Further, it allows partitioning of models based on an 
organization’s procedures and the processes that make up these procedures. 

The lEF bases the Planning phase on user involvement, however, 
all toolsets rely heavily on systems analysts and programmers for guidance on use 
of the methodology and for operation of the system. This is contrary to lESC’s 
product, which is highly user-driven. With the lEF, users tend to distance 
themselves from the systems development process after Information Strategy 
Planning, leaving the process to ADP-types. User involvement is a vital 
prerequisite to the success of an IE project, and therefore, the organization must 
stress continued involvement from non-ADP personnel after the Planning phase 
is complete. Another drawback of the lEF is that it doesn’t support the rigorous 
data analysis and normalization that the lESC product does. It normalizes to 
third normal form (3NF), as opposed to lESC, which fully normalizes data to fifth 
normal form. As a result, the lEF-produced business model will not be as 
rigorous and stable as the lESC data model. Further, lESC’s data analysis and 
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planning process is much more comprehensive, with a stronger foundation of 
methodology training. On the other hand, lEF provides full back-end support 
through code generation, and a centrally managed information repository at the 
mainframe level; two features not supported by the lESC product. NAVSUP- 
0482, project manager for SUADPS, identified the tradeoffs between the lEF and 
USER: Expert Systems, and developed an automated bridge between the two. 
This bridge allows them to take advantage of the strong front-end features of the 
lESC product, combined with the back-end features and Central Encyclopedia of 
the lEF. 

3. KnowledgeWare’s Information Engineering Workbench (lEW) 
a. Overview 

KnowledgeWare was founded as Database Design, Inc. in 1979 by 
James Martin, as a research, development, and consulting firm. In 1985, it 
became KnowledgeWare, Inc., and in 1986, merged with Tarkenton Software, in 
order to add application generation to its product portfolio. Today, 
KnowledgeWare is the world’s largest vendor of CASE tools. The company’s 
strategic product line, the Information Engineering Workbench (lEW), is a CASE 
toolset consisting of three PC-based diagramming tools for planning, analysis, and 
design, a PC-based COBOL generator, and a mainframe-based COBOL generator. 
All of these products revolve around, and are integrated with, a central 
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encyclopedia. The lEW utilizes an open architecture approach that allows for 
ready interface with other company’s software products. On the other hand, 
KnowledgeWare has entered into a fully cooperative marketing agreement with 
IBM, and as such, lEW has been designed and updated to maintain full 
compatibility with IBM hardware and software products. 

b. Methodology 

The Information Engineering Workbench is not aligned to a specific 

methodology. KnowledgeWare’s reasoning for this is that their tool is built 

around general software principles, and as a result, provides the developer with 

more flexibility to tailor the tool to their needs. They state that: 

Few development shops can apply a strict methodology to every 
development or maintenance project. Many employ multiple methodologies 
or ’home grown’ hybrids. And everyone is faced with the ’quick and dirty’ 
applications that don’t warrant a comprehensive formal technique. 

[Ref. 20:p. 2] 

KnowledgeWare states that users of the lEW are free to employ Martin’s 
Information Engineering, Yourdon, DeMarco, Arthur Young, Constantine, 
Rockart’s CSFs, BSP, SSP, JAD, Prototyping, and many other methodologies. 
They maintain that their product maintains the necessary engineering discipline 
over the systems development process, without "constraining" it to a specific 
methodology. 
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c. lEW Software Product Overview 

The lEW workstation tools provide easy-to-use, mouse- driven 
applications for creating, revising, and maintaining most common systems 
development diagrams. All the tools are fully integrated with the central 
Encyclopedia, and use the expert system Knowledge Coordinator. The Knowledge 
Coordinator ensures the consistency, correctness, and completeness of all diagrams 
on a real time basis. There are six workstations that comprise the full lEW 
product: (Figure 14) 

1. Planning workstation 

2. Analysis workstation 

3. Design workstation 

4. Mainframe Knowledge Coordinator and Encyclopedia 

5. PC-based Construction Workstation 

6. Mainframe-based GAMMA workstation. 

Appendix D provides hardware requirements for lEW. Product descriptions are 
listed below:’ 

The Planning Workstation (lEW/PWS) is a tool for managing and 
analyzing planning data. It helps the systems analyst define an information 
architecture by grouping and prioritizing activities and data into subject data 


*S<pftwire product detcriptiont io this tecdoo driwn from Ref. t9:pp. 6-9. 
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bases. Further, it helps the analyst organize, model, and evaluate knowledge 
about the enterprise-its processes, funcdons, and data, and its organizational 
information needs. All diagrams are integrated using the Knowledge Coordinator 
to ensure consistency between diagrams. The following diagrams support the 
Planning Workstation: 

1. Association Matrix Diagrammer: performs cross-analysis between any two 
objects of a strategic plan, providing a means to document and modify the 
information requirements of the business and the interrelationships between 
them. 

2. Propeny Matrix Diagrammer: assigns characteristics, properties, and 
priorities to individual planning objects. 

3. Entity Diagrammer: graphic method for describing the information needs 
of the enterprise. It allows the identification of principal entity types and 
the relationships between them. 

4. Decomposition Diagrammer: Creates and maintains hierarchy diagrams and 
hierarchical relationships, and alens the analysts to circular relationships. 

The Analysis Workstation (lEW/AWS) provides diagramming tools 
for both process and data modeling, arthe definition of system specifications. 
It is integrated with the Planning Workstation through the Encyclopedia, and 
provides diagramming techniques that support many structured analysis techniques. 
The following tools support the Analysis Workstation: 

\. Decomposition Diagrammer: refines high level business activities into lower 
levels of detail. 

2. Data Flow Diagrammer: describes the processes of the system and how 
data flows between these processes. 










3. Entity-Relationship Diagrammer: defines data requirements for the 
processes, subject area data bases, and the system as a whole. 

4. Action Diagrammer: describes the procedural logic for the lowest level 
processes in the organization. 

The Design Workstation (lEW /DWS) supports the transformation 
of logical representation of the system to the physical design. It supports both 
process and data-oriented design, and helps the designer capture knowledge about 
screen layouts, edit rules, program structures, procedural logic, and data base and 
file structures. All diagrams, and the movement between those diagrams, are 
stored in the Encyclopedia, and are managed by the Knowledge Coordinator. The 
following diagrams support the Design Workstation: 


1. Structure Chart Diagrammer: describes the hierarchy between modules, 
along with the data that is passed between those modules. 

2. Action Diagrammer for Modules: describe detailed program logic and refer 
to other design objects like screens, subordinate modules, segments, 
relations, and records. 

3. Presentation Diagrammer for Screens: speeds screen design using mouse 
and graphics capabilities. 

4. Data Structure Diagrammer: creates and maintains record, relation, 
segment, and screen data structures graphically. 

5. Database Diagrammer: represents the physical data base design for 
relational, hierarchical, and flat file data base implementations. 
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The Mainframe Knowledge Coordinator and Encyclopedia 
(lEW/MF) provides the analyst and designer with project management, security, 
reporting, and shared access capabilities. It facilitates the sharing of information 
between multiple lEW workstation users, and consolidates their work into a 
mainframe resident central encyclopedia. 

There are two application generators available as part of the lEW 
toolset; the PC-based lEW Construction Workstation (lEW/CWS), and the 
mainframe-based lEW/GAMMA. Both provide full COBOL source code 
generation and documentation from the previously defined design specifications. 
From the design specifications, both tools generate 100 percent of the application 
including full COBOL source code, screen maps, data base access routines, DDL, 
and full documentation. 

d. Assessment of the Information Engineering Workbench 

The Information Engineering Workbench’s open architecture 
approach is a significant selling point for the product. Every toolset has import 
and export capabilities that allow them to take advantage of other tools in the 
lEW package, or be used in conjunction with other firm’s software products. The 
tool provides capability to interface with 4GL products, DBMS’, desktop 
publishers, code generators, data dictionaries, and spread sheets. 

The lEW workstations can be used as one integrated toolset or as 
separate tools to meet a specific stage of the development lifecycle. As such, the 
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lEW offers the integration of a single-vendor solution, or the flexibility of 
modularity. On the other hand, since the product can be used either way, it does 
not provide the rigid discipline necessary for an effective, engineered, systems 
development process. This is due to the fact that the lEW is not based on a 
specific methodology. KnowledgeWare states that this approach leads to more 
flexibility for the system developer, and makes it possible to use the tool to 
create "quick and dirty" applications. "Quick and dirty" applications are exactly 
what organizations should steer away from. An integrated toolset based on a 
specific, rigid methodology is necessary in order to provide the organization with 
the rigorous data analysis and validation necessary to create strategic information 
systems. KnowledgeWare does not provide training workshops or technical 
support as part of their package. 

4. Comparison of CASE Toolsets 

Both the TI and lESC tools support Information Engineering exclusively, 
as opposed to lEW, which professes to support both data and process orientations 
through a combination of methodologies. As a result of its "open" methodology, 
lEW lacks the rigorous data analysis, validation capabilities, and discipline needed 
for the development of strategic information systems. The lESC product has the 
strongest data analysis capabilities, in that it is capable of normalization to 5NF. 
It does not, however, support any process-oriented analysis. 
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Both lEF and lEW provide strong back-end support as well as a central 
encyclopedia for integrating diagrams and stages. The lESC product, on the other 
hand, does not provide a fully developjed back-end, nor does it provide a 
centralized data repository. Both issues are currently being rectified by lESC. 

The lESC product provides the most comprehensive training and 
technical support program of the three. It is oriented towards training in both the 
Information Engineering methodology, and towards profidency in using the 
product. lEF training workshops are specifically designed to train users on how 
to run the package. lEW provides no technical support with its package. The 
training programs available reflect the policies of each firm. Whereas lESC bases 
the use of its product on full participation of the user and management 
throughout the process, lEF is geared towards IS personnel after the initial 
planning phase. lEW represents a CASE tool specifically developed for use by 
systems analysts and designers. 

lEW is the least expensive of the three products, however it provides 
the least benefits as well. The TI and lESC tools cost approximately the same 
for providing the same coverage. The addition of back-end support must be 
figured into the cost of the lESC product, while the cost of mainframe support 
must be figured into the price of the H product. The lESC product is fully 
microcomputer-based, whereas the TI product requires both PC and mainframe 
support. lEW offers either PC or mainframe support. 
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The next section will compare the lifecycle coverage of the three CASE 
workbenches in the context of an analytical framework for comparing IE methods, 
proposed by Hackathom and Karimi. TABLE 1 provides a graphical comparison 
of the three products. 

S. A Framework for Comparing Information Engineering Methods 
a. Description 

The analytical framework for comparing information engineering 
(IE) methods presented here was developed by Dr. Jahangir Karimi and Dr. 
Richard Hackathom of the University of Colorado at Denver. It encompasses 
two dimensions, depth and breadth, which form the axes of a graph (called the 
DB-space) that compares the IE methods. The framework suggests roles for 
developers and planners, and two processes, align and exploit, that ensure that 
organizational goals and the information systems architecture are properly aligned. 
[Ref. 2:p. 205] 

The breadth dimension of the framework is composed of five 
phases, and represents an extension of the traditional systems development 
lifecycle. It is extended in that it includes strategic considerations not covered in 
the systems lifecycle. The breadth dimension describes both what is being done, 
an activity, and what will result, the deliverable. Each activity and its associated 
deliverable is referred to as a phase. (Figure 15) Note that the first four phases 
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TABLE I 


CASE TOOL COMPARISON 



lESC 

lEF 

lEW 

Methodology 

data 

data 

open 

PC/mainframe 

PC 

must use both 

either 

Normalization 

5NF 

3NF plus 

3NF 

Interface 

good 

excellent 

excellent 

Availability 

NAVDAC 

contract 

GSA 

GSA 

PC Toolset 

$135K 

$89K 

$107K 

Mainframe Tool 

N/A 

$207K 

$164K 

Technical 

Support 

$275K 

$200K 

not provided 

Total Cost 

~$500K 

$495K 

$27IK (tools 
only) 


[Ref. 21] 
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are global to the organization, and closely parallel the phases of information 
engineering. The last phase of the dimension is local to a specific application, 
and is software engineering oriented. 

The five activities of the breadth dimension are; Organizational 
Analysis, Strategy to Requirements Transformation, Logical Systems Design, 
Logical to Physical Transformation, and Systems Implementation. The first phase, 
Organizational Analysis, is the most vital, and in most cases, the most overlooked. 
The purpose of the phase is to conduct an analysis of the mission and nature of 
the organization and its environment, and to translate this into a formal statement 
of organizational goals and strategies. Phase two. Strategy to Requirements 
Transformation, entails modeling of the information systems architecture (ISA) 
which represents the information flow requirements of the entire organization. 
Data, applications, geographic, and communications architectures are also defined 
in phase two. "Planning for ISA should specifically include the implications of the 
business objectives and the organizational strategic plan on the strategic direc¬ 
tion setting of information systems technology. It requires primarily business- 
oriented people who understand the information requirements of the organization." 
[Ref. 22;p. 11] The third phase of the Breadth dimension is Logical Systems 
Design. Its purpose is to conduct the design of the data, application, and 
geographic architectures using the logical model of the ISA. Phase four, Logical 
to Physical Transformation, consists of the decomposition of the architectures 
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discussed above, the formulation of an applications portfolio, and decision making 
regarding detailed design and implementation. The final phase, Systems 
Implementation, occurs for each application designed in the previous phases. The 
result is an operational application that supports a business function of the 
organization. 

The Depth dimension of the framework allows review of 
information engineering methods as they relate to both their conceptual 
foundation and practical results. It is composed of three stages; methodology, 
technique, and tool. The first stage, methodology, defines the conceptual basis 
of an IE activity. The second stage, technique, specifies the steps in performing 
a specific IE activity, including the required inputs to and results from each step. 
The final stage, tool, represents a tangible aid for performing a specific IE activity 
for example, a CASE tool. The purpose of using a tool is to produce a 
deliverable. 

The two dimensions are used together to produce the framework, 
called the DB-space, for comparing IE methods. (Figure 16) The breadth 
dimension is used as the horizontal axis, with the depth dimeiisiou as the vertical 
axis. 

Considering the nature of the four quadrants in Figure 15, one can 
characterize organizational roles to support the development process. 
Counterclockwise from the upper left, these roles are: [Ref. 22:p. 15] 
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Figure 16. The DB-Space [Ref. 2:p. 209] 
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1. Conceptual Planner: concerned with organizational strategic planning and 
direction setting, and the establishment of corporate IS strategy. 

2. Pragmatic Planner: concerned with modeling organizational structure, plans, 
policies, procedures, and investment strategies to derive the IS architecture 
(ISA). 

3. Pragmatic Developer: concerned with implementing the ISA. 

4. Conceptual Developer: concerned with conceptual basis for employing 
technology to meet organizational goals and needs. 

A continual dialogue or process should occur between the 
Conceptual Planner and the Pragmatic Developer to ensure that the organization’s 
IS is fully aligned to organizational goals while being able to exploit emerging 
technologies. These processes are referred to respectively, as Align and Exploit. 
The Align process seeks to force IS management to conform to the mission and 
policies of the organization. The Exploit process seeks to identify and exploit 
opportunities that are feasible given the current state of the organization and 
technology. [Ref. 2:p. 216] Since these two roles are on separate conceptual 
levels, the Align process should involve the Pragmatic Planner, and the Exploit 
process should involve the Conceptual Developer. They will act as intermediaries 
to ensure clear lines of communication over the two processes. (Figure 17) A 
clear linkage between the Conceptual Planner and the Pragmatic Developer will 
ensure that the IS architecture is fully aligned to the overall business plan of the 
organization. (Figure 18) 


97 












CONCEPTUAL PLANNER CONCEPTUAL DEVELOPER 





Figure 18. Aligning Strategic and IS Planning [Ref. 22:p. 14] 
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The parameters used for comparing IE methods are based on two 
major characteristics: the extent of coverage over the depth dimension, and the 
extent of coverage over the breadth dimension. Extent of coverage over the 
depth dimension details the following: the knowledge threshold of the input or 
analysis employed, from conceptual to machine processable (tool); the extent of 
knowledge provided by the output, from conceptual to machine processable; and 
the extent of coverage of each, from no coverage, to partial, to extensive. Extent 
of coverage over the breadth dimension examines the extent to which an IE 
method covers the lifecycle. It looks at where inputs are generated, where 
outputs are produced, and the coverage of each method over the applicable part 
of the lifecycle. Based on the results of the elimination of theses parameters, the 
IE method will be mapped onto the DB-space. The size and placement of the 
boxes representing each method indicates the relative coverage of the method 
over the breadth and depth dimensions of the framework. The framework does 
not subjectively rate one method over another, but simply gives the planner an 
indication of which methods provide the necessary coverage over the dimensions 
of the framework for the application in question. It also provides an excellent 
mechanism for comparison and integration of the methods, in order to gain the 
most complete coverage of the systems lifecycle as is practicable. 
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b. Using the Framework to Determine Coverage of Toolsets 


Hackathorn and Karimi’s framework represents an easy-to- 
understand graphical method of comparing the coverage of various CASE tools 
using common criteria. As stated earlier, it does not subjectively rate one tool 
over another, but it does provide the planner with an effective diagnostic method 
for determining the combination of tools needed to ensure full coverage over the 
development lifecycle. In this section, each CASE workbench discussed earlier 
will be rated in accordance with the evaluation criteria of the framework, and 
then mapped on to the DB-space to graphically illustrate the results. These 
ratings will be performed subjectively, based on contacts with vendors and users, 
supporting literature, and some personal experience. Figure 19 illustrates the 
coverage ratings given; Figure 20 compares the CASE workbenches in the context 
of the framework. 

One can see from Figure 20 that no single CASE tool provides full 
coverage over the breadth and depth dimensions. Note however, that using a 
combination of tools, full coverage can be accomplished. Ideally, the combination 
of tools selected should provide full coverage over all fifteen sectors of the DB- 
space. Integration of lEF and USER: Expert Systems would accomplish this, and 
woidd fully exploit the advantages of each product. 
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Figure 19. Comparison of CASE Tools 
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V. CONCLUSION 


SECNAV Instruction 5230.9A, the Information Resource (IR) Program 
Planning guide, and SECNAV Instruction 5230.10, the Department of the Navy 
Strategic Plan for Managing Information and Related Resources 
(IRSTRATPLAN), document the Navy’s commitment to a top-down approach to 
strategic IS planning. However, in practice, its efforts have not been particularly 
successful. Huge cost overruns, unnecessary duplication, the inability to integrate 
existing systems, and overall program mismanagement have resulted in a loss of 
credibility and confidence for the DON in Congress. There are several reasons 
for these difficulties. One of the primary reasons is the lack of understanding by 
top DON management of Information Resource Management (IRM) issues, and 
in particular, the methodologies and tools available for aligning strategic and 
information systems planning. Uneasiness regarding the need for IRM and IR 
planning, the organizational structure required to support IRM, and the relative 
strengths and weaknesses of the various IS planning tools and methodologies, all 
add to the reluctance of top management to embrace these issues. Second, the 
reluctance of top management to conmiit considerable resources to what is 
perceived to be an uncertain process, further complicate the IRM and IR planning 
process. This problem has been further complicated by the recent CIM initiative. 
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which has essentially put a hold on the Navy’s efforts to pursue effective IR 
planning and management. It is important for DON management to understand 
that IS planning methodologies are not a panacea and do not provide an 
overnight payback. The large up front investment in time and capital required 
will yield benefits downstream, and over the long run, not overnight. A 
commitment to education at all levels of both the IS and line communities is 
required to improve the overall performance of DON system development and 
program management. 

The impact of information technolog>' varies widely between DON 
organizations, and these differences influence greatly how IS planning can best be 
accomplished. Four factors influence how the DON should structure its IR 
planning in order to succeed. First, the organizational placement of IS 
management must suit the role that the information system plays in the 
competitive strategy of the business. In many organizations, including the 
Department of the Navy, IS management is relegated to the departmental level 
despite the strategic significance of both existing IS, and its applications 
development portfolio. As a result, IS is perceived by top management, not as 
a corporate resource, but in a supporting role. Thus, the IR planning process was 
relegated to the same position. The location of IS management in the 
organizational structure must be high enough for the manager to have the political 
strength essential to positively plan and implement IS strategy, plans, and policies. 
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Second, information systems and general management must be in close proximity, 
both physically and logically, in order to facilitate the IS planning process. Face 
to face interaction is vital to ensure that all information requirements are 
identified, communicated, and met. Third, as the formality of the organization’s 
management style and corporate culture increases, so must the formality of the 
IS planning process. In a formal organizational environment such as in the 
Department of the Navy, there is no room for informal planning processes that 
are incapable of fulfilling all requirements. Finally, as the size and complexity 
of the organization increases, the need for formal IS planning processes increases 
accordingly. This is necessary to ensure the "broad based dialogue that is 
essential to the development of an integrated vision of IS." [Ref. 8:p. 156] If 
these factors are taken into account, and are handled properly, IS planning can 
establish the required structural linkage between the business plan and the IS 
plan, and between IS management and senior line management. 

Information Engineering provides an excellent opportunity to solve many of 
the problems plaguing IR planning, development, and management in the DON. 
It is the most capable methodology available for integrating the diverse 
information needs of Navy organizations, and represents a significant improvement 
over BSP or process-oriented methodologies. The following are some of the more 
important benefits of IE when used in DON applications: 
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1. Objectives-driven approach ensures that the resulting information systems 
are fully supportive of the overall corporate strategy. 

2. Data-oriented approach identifies data fundamental to the organization, 
and provides a stable foundation on which to base systems development. 
Further, it provides for standardization of data across diverse organizational 
boundaries, allowing for integration. 

3. Technology-independence allows for upgrades and changes in procedures, 
hardware, DBMS’, etc. without affecting the stability of the data model. 

4. It provides for rapid feedback to users and management, reducing systems 
development time, and increasing confidence in the system. 

5. It is capable of being fully automated through the use of CASE 
workbenches, speeding up development considerably. 

6. It drastically improves the quality of the resultant information systems, 
thereby significantly reducing maintenance costs. 

7. It facilitates standardization and Data Administration by providing 
consistent standards for defining, accessing, processing, and changing data. 

8. It improves user and management satisfaction because they receive the 
system that meets their needs quickly. 

9. It significantly reduces total lifecycle costs. 


Three CASE workbenches that support IE either in part or exclusively were 
discussed. Two, Texas Instruments’ lEF and lESC’s USER: Expert Systems were 
shown to be effective tools for automating the IE process. lESC’s product was 
determined to be the best "front-end" tool, as a result of its rigorous data analysis 
and modeling capabilities, allowing data normalization to 5NF. In addition, it 
provided the most comprehensive training and technical support of the three. 
TI’s tool was determined to provide the most effective "back-end" support, with 
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the added advantage of a centrally managed data repository. KnowledgeWare’s 
lEW was not recommended due to its open methodology approach, which doesn’t 
provide the rigorous structure, or the data analysis and validation required for 
building strategic information systems. In addition, it does not provide 
methodology training or technical support to supplement its product. None of the 
three workbenches provided full coverage over the depth and breadth of 
Hackathom and Karimi’s framework. As a result, the combination of using the 
lESC tool for front-end support, and the Tl tool for back-end support and code 
generation, would be the optimal combination. NAVSUP 0482, project manager 
for the SUADPS project, has developed an automated bridge between the two 
products to facilitate integration. 
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APPENDIX A 


[Ref. 23] 


Software Support Tools: 

A. Automated Data Dictionaries: 

There are four levels of automated data dictionaries: 

1. CLASS 1: Passive data dictionaries 

2. CLASS 2: Active, integrated data dictionaries 

3. CLASS 3: DP-driven design dictionaries 

4. User-driven expert systems design dictionaries 

Classes 1 and 2 do not provide support for automated analysis and design of 
information systems; most products on the market are one of these two. Qasses 
3 and 4 are both data and design dictionaries. All three CASE products discussed 
provide Class 4 support. 

B. Automated Data Modeling: 

There are two levels of automated data modeling available in CASE 

tools: 

1. LEVEL 1: Passive data modeling 

2. LEVEL 2: Expert data modeling 
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Level 1 tools provide a passive capability for the development and maintenance 
of data models. They must be manually entered and maintained. Level 2 tools 
provide expert data modeling that is fully integrated with a Class 3 or 4 data 
dictionary. 

C. Automated Documentation: 

There are two levels of documentation support: 

1. LEVEL 1: Manual documentation 

2. LEVEL 2: Active documentation 

In Level 1 documentation, changes must be input manually, and there is little 
support for consistency checking. Level 2 documentation is fully integrated with 
a class 3 or 4 data dictionary. Updates and changes occur automatically as design 
changes are made. 







APPENDIX B 


[Ref. 17:pp. 3-4] 

USER: Expert Systems Hardware Requirements: 

A. Personal Computers: 

1. Any fully compatible XT/AT/386 machine 

2. XT/AT compatible hard disk (20 Mb min., 40 Mb recommended) 

B. Plotters: 

1. PH7475A six pen plotter 

2. Any fully compatible HP7475 plotter 

3. GRAPHTEK 23000 graphics plotter 

C. Printers: 

1. IBM graphics printer or fully compatible 

D. Monitors: 

1. Coior preferable due to use of colors in software. 

E. Memory Requirements: 

1. Software requires almost all available RAM, and cannot operate 
concurrently with memory resident programs. 
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APPENDIX C 


[Ref. 19] 

lEF Hardware Requirements: 

A. lEF Mainframe Operating Environment; 

1. IBM MVS operating system: 

a. DB2 

2. TSO/E 

3. ISPF Version 2.2 

4. VS COBOL II 

B. lEF PC Operating Environment: 

1. PC-DOS, MS-DOS 3.0 or higher 

2. Workstation-mainframe communications using IRMA and FORTE 
PJ (3278/79) boards 

3. Plotters/printers 

4. IBM AT, PS/2 Models 50, 60, 80, and compatibles 

5. EGA graphics 

6. Mouse 
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APPENDIX D 


[Ref. 20] 

lEW Hardware Requirements: 

A. JEW PC-based Tools: 

1. IBM PS/2 Model 50 or higher w/ DOS 3.3, or IBM PC/AT w/ 
DOS 3.1: 

a. 20 Mb hard disk 

b. High density disk drive 

3. 5 Mb RAM 

4. Mouse 

5. VGA/EGA/CGA graphics 

6. Laser or high resolution graphics printer 

2. IBM 3270/AT (monochrome only for high resolution) 

1. 5273 System unit, model 062 

2. IBM 5272 color display 

3. 20 Mb hard disk 

4. High density disk drive 

5. 5 Mb RAM 

6. Mouse 

7. Laser or high resolution graphics printer. 
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B. lEW Mainframe Tools: 


1. lEW/GAMMA Application Generator: 

1. IBM mainframe or plug compatible under MVS supporting 
ANSI standard COBOL and VSAM 

2 . TSO/ISPF and ISPF/PDF version 2.0 or later and TSO/E 

2. lEW/MF Mainframe Knowledge Coordinator and Encyclopedia: 

1. IBM mainframe or plug compatible under MVS/SP with 
TSO/E release 2, ISPF/PDF V 2 R2, and MVS PROLOG, 
5798-DYL 

2. 4 Mb region size minimum, 6 Mb recommended 

3. IBM file transfer software for host-PC link 
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